Version Control #

TLDR: Every change to the source is logged and tracked in a version control system

Rationale: Version control allows us to keep track of and manage changes to the code in a special kind of database. As a traceability system, it provides a means to understand how our software has changed, who changed it, and why it was changed.

Background #

We use git to manage versioning for software development source code. For repository hosting and user management we use GitHub, Bitbucket and Azure DevOps.

Defining code owners #

It is important to define ownership of code repositories to be able to implement rules about requiring code reviews from the right people to accept changes. When using GitHub this can be achieved using CODEOWNER feature as defined in the article About code owners

All the repositories owned by a specific team should have CODEOWNER group defined.

Branching Strategies #

A branching strategy defines how the “branch” feature is used in the in git to deliver the software to production. The key goals of these strategies are the following:

1. Provide control over production code
2. Allow compliance processes to be integrated
3. Keep the software development lifecycle agile

We will use the following branching strategies. Every service will follow one of the these strategies.

1. Feature Branch + Pull Request, or:
2. GitFlow

These are described below.

1. Feature Branch + Pull Request #

This branching strategy uses a combination of feature branches with pull requests.

• main branch is protected and holds the production ready code
• All development is done in feature branches which must be created from the main branch
• A pull request must be created to merge a feature branch to the main branch
• Pull requests must run pre-defined validations and must pass them
• Pull requests must be approved before merging to the main branch.
• Pull request merges should create a separate new commit.

We use pull requests to enforce checks and document our Code Review Process

Merging to the main branch should use either “Create a merge commit” or “Squash and merge” option. “Rebase and merge” and the “Fast-forward merge” options must not be used. This allows us to atomically back out merges should we need to.

2. Feature + Release Branch + Pull Request #

This branching strategy uses additional release branches in combination with feature branches to allow aggregating of multiple features and testing them.

• main branch is protected and holds the production ready code
• All development is done in feature branches which must be created from the main branch
• A pull request must be created to merge a feature branch to a release branch
• Changes in a release branch is tested (multiple features) on a specific environment
• A pull request must be created to merge a release branch to the main branch
• Pull requests must run pre-defined validations and must pass them
• Pull requests must be approved before merging to the main branch.
• Pull request merges should create a separate new commit.

Protected Deployment Branches #

By choosing to protect certain branches we can control the changes being pushed to important branches. This allows us to apply rules before changes are applied to a branch.

To ensure compliance to the code review process, we protect the branch we deploy from (main or production) with the following requirements:

• Merges require at least one approval (We will need additional approvals for repositories deploying to customer production environments)
• Builds and tests run successfully (Depending on the project type these can also be validations)
• Correct semantic versioning is used
• No unresolved merge checks