Managing source code with Azure repos

Following the practices in this section aligns with Using Source Control, improving traceability, linking work items to code changes, and enhancing code quality.

How do you branch and release?

You have freedom to choose your branching and release strategies, but you SHOULD follow these key practices to maintain simplicity and consistency:

• Use feature branches: Develop new features and fix bugs in dedicated branches.

• Merge through pull requests (PRs): Integrate changes into the main branch using PRs.

• Keep the main branch clean: Ensure the main branch is functional & up to date.

• Git Tagging: Tag the release commit to ensure traceability and version identification.

Recommended naming conventions

Name Git repositories in lowercase with hyphens. Prefixing with the Azure DevOps project or team name is RECOMMENDED but not required.

Use this convention for branch names. You may not need them all, it depends on your strategy.

Configure repository settings for commit linking

You SHOULD ensure these settings are applied across all branches:

• Enable Commit Mention Linking: Automatically link commits to work items by including the work item ID (e.g., #123) in the commit message.

• Ensure Work Item Resolution: Automatically update work item status based on commit actions.

Configure repository policies for email validation

• Commit author email validation: Block pushes from emails not matching .*@wales\.nhs\.uk\$

Configure branch policies

Enable these settings on main and release branches to support effective branching and release:

• Require a minimum number of reviewers: Ensure pull requests are subject to code review.

• Require linked work items: Ensure pull requests are linked to work items.

• Require comments resolution: Address comments before merging pull requests.

• Enable Build Validation: Trigger a build pipeline on pull requests to validate code quality.

• Add a Code Coverage Status Check: Ensure coverage targets are met before merging.

• Set Coverage Thresholds: Define differential (diff) thresholds in azurepipelines-coverage.yml or .runsettings to match your Definition of Done.

• Address Insufficient Coverage: Use the "Require comments resolution" policy to address any insufficient coverage before merging.

• Review Coverage Thresholds: Regularly review thresholds to meet quality standards.