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:

Merged with the master branch (in isolation)
Built, to ensure compatibility
Tested via unit tests, to ensure quality
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