Skip to content

development-process.md

Latest commit

 

History

History
67 lines (48 loc) · 4.39 KB

development-process.md

File metadata and controls

67 lines (48 loc) · 4.39 KB
Raw

Development Process

This document describes the team workflow and configuration-management baseline for Sprint 3 and later work.

Workflow

gitGraph
  commit id: "main"
  branch feature-issue
  checkout feature-issue
  commit id: "implement"
  commit id: "test-docs"
  checkout main
  merge feature-issue id: "reviewed MR"
  commit id: "release tag"
Loading

The diagram shows the normal issue-linked workflow: create a short-lived branch from main, implement the PBI, update tests and documentation, open a merge request, pass CI, receive review from a different team member, and merge to the protected default branch.

Branches and Reviews

  • main is the protected default branch.
  • Feature branches should reference the related issue or PBI.
  • Merge requests must link the issue, summarize the change, include verification evidence, and be reviewed by someone other than the implementer.
  • Release tags are created from protected main commits.

Sprint Tracking

  • Product Backlog items are tracked as GitLab issues.
  • Sprint scope is selected through the Sprint milestone.
  • Issue status, assignee, reviewer, story points, and acceptance criteria must stay inspectable in GitLab.
  • User-story issues must use .gitlab/issue_templates/User Story.md; the repository index in docs/user-stories.md must remain synchronized with issue state.
  • Closed is a GitLab lifecycle state, while To Do, In Progress, In Review, and Done describe work status. A closed issue must not be reported as In Progress; if work remains, reopen it or create and link a follow-up issue.

Inspectable Boards and Sprint Views

The milestone issue views are the authoritative selected Sprint Backlogs. docs/user-stories.md is a readable traceability index, not a replacement board.

Work Status and Entry Criteria

Work Status Entry criteria
To Do Expected outcome, acceptance criteria, Story Points, milestone, implementer, and different reviewer are recorded.
In Progress The implementer has started an issue-linked branch and is actively changing the product or maintained artifact.
In Review An issue-linked MR is open, implementation is complete, relevant checks pass locally, and acceptance evidence is ready for reviewer inspection.
Done Acceptance criteria and DoD are checked, CI passes, discussions are resolved, maintained documentation is current, and the MR is merged.

Configuration Management

  • Secrets, credentials, private access links, and customer-identifying evidence must not be committed.
  • Public examples belong in .env.example or documentation placeholders.
  • Runtime configuration is provided through environment variables.
  • CI must pass before merge, including relevant tests and quality checks.
  • Closes #<issue> is used only when the merge request satisfies every acceptance criterion. Partial work uses Relates to #<issue> and leaves the issue open.

Reproducible Environment

The root README is the setup authority. Developers use the documented Python virtual environment and locked frontend dependencies. Local backend configuration starts from MVP-v2/backend/app/.env.example; .env, credentials, build output, caches, and coverage output are ignored. Verification commands are maintained in Testing and AGENTS.md.

CI and Deployment Automation

Merge-request, protected-default-branch, and tag pipelines enforce links, secret scanning, lint/format checks, backend and frontend tests, integration/QRT checks, coverage thresholds, and the frontend production build. Coverage reports and the frontend bundle are retained as temporary CI artifacts. GitLab Pages publishes public documentation only from protected main. The running OMS product remains team-operated; deployment/recovery responsibilities and the achieved transition level are documented in Customer Handover.