Skip to content
ASP Development

Your web browser is out of date

Your web browser (the software you use to access the internet) is out of date. You need to update it or use a different web browser to ensure you can complete this form.

Cookies disabled

Cookies are currently not enabled in your web browser. You need to enable cookies to ensure you can complete this form.

Gitflow and releases

Overview

We use a Gitflow-style workflow and continuous integration so the team can work with minimal friction. We refine the details through retrospectives and lessons learned.

Protect the master branch

The master branch is the most stable branch of a product. It must be protected by branch policies. Direct ad hoc changes to master should be extremely difficult, if not impossible.

Branching

All development must be done in a branch off master, using one of these naming conventions:

  • feature/work-item-name
  • bugfix/work-item-name
  • username/custom-name (for experimental and/or R&D work)

Pull requests

Pull requests must be used to merge branches back to master. They are the place for code review and discussion. Work is signed off not only by the developer, but by their peers.

Continuous integration

Code subject to a pull request is automatically:

  1. Merged with the master branch (in isolation)
  2. Built, to ensure compatibility
  3. Tested via unit tests, to ensure quality
  4. Deployed to an as-live dev environment for human verification

Releases

Our release cycle follows continuous deployment and continuous delivery principles.

After code review and peer approval, the branch is merged into master and removed. That automatically triggers a deployment to an as-live staging environment for product owner review (the product owner receives an email indicating the work to review).

The product owner then has two choices:

  • Approve the release — staging is promoted to live
  • Reject the release — next steps depend on the reason

We follow a never rollback strategy because of the risks and complexity of rollbacks. If a fix is needed after rejection (or after go-live), we create a new branch and follow the same principles above.

Published 21 September 2026
Last updated 21 September 2026