Skip to content

4. Development & Code Review
What Writing code and tests, running static analysis, and reviewing every change before it merges.
Owner Engineering: the author writes and tests, an assigned reviewer approves.
Triggers When a developer picks up a ticket from the committed sprint backlog.

Summary

Development happens on a dedicated feature or bug branch off the release branch. The author is responsible for working code, unit tests, and passing the static analysis quality gate before asking for review. Nothing merges into the release branch without a pull request and at least one approving reviewer. Code review is a quality gate and a knowledge-sharing mechanism, not a formality. AI-assisted development is a first-class part of this phase and is covered by the AI-Assisted Development standard.

Full detail

Developer responsibilities

  • Develop and maintain code per the agreed requirements and coding standards.
  • Write unit tests for new and changed logic.
  • Review the existing code in the area being changed so the change fits the current design.
  • Run static analysis locally and resolve issues before opening a PR.
  • Log work hours daily at the sub-task level in the tracker.
  • Communicate blockers to the Project Manager promptly.

The quality gate before review

Before a pull request is opened, the change MUST clear:

  1. Unit tests for new and modified behavior, passing locally and in CI.
  2. Static code analysis (for example a SonarQube scan). The change must not introduce new issues that breach the agreed quality gate.
  3. Code smell threshold: no new blocker or critical issues; code smells kept at or below the project's configured gate.

Quality-gate thresholds are configurable

Exact thresholds (coverage percentage, allowed code smells, duplication) are set per project in the analysis tool, not hard-coded here. The rule is that the configured gate MUST pass; the numbers themselves live with the project.

The pull request

A pull request MUST:

  • Target the correct branch (the active release branch, or the hotfix branch during a hotfix).
  • Use the PR/MR template so the reviewer has context, testing notes, and linked tickets.
  • Reference its JIRA ticket so code, tracking, and review stay connected.
  • Have at least one assigned reviewer. The author does not merge their own unreviewed code.

Code review expectations

The reviewer checks correctness, test coverage, adherence to standards, and whether the change introduces risk to areas outside its stated scope. Reviews can take multiple rounds; the author addresses comments and re-requests review. Use the code review checklist as the baseline.

flowchart TD
    A[Pick ticket from sprint backlog] --> B[Branch feature or bug off release branch]
    B --> C[Develop + write unit tests]
    C --> D[Review existing code in the area]
    D --> E[Run static analysis locally]
    E --> F{Quality gate passes?}
    F -->|no| C
    F -->|yes| G[Open PR with template + linked ticket]
    G --> H[Assigned reviewer reviews]
    H --> I{Approved?}
    I -->|changes requested| C
    I -->|approved| J[Merge into release branch]
    J --> K[Log hours, update ticket status]

Example

A developer on feature/ABC-1310 adds a CSV export endpoint. They write unit tests for the formatting and date-handling logic, run the SonarQube scan locally and fix two code smells it flags, then open a PR into release/v1.4.0 using the template, linking ABC-1310 and noting how they tested it. The reviewer asks for a null-safety fix on one input path; the author addresses it, the reviewer approves, and it merges. The ticket moves to its next status and hours are logged.