Evolving the Dev Process
Over the last few weeks we’ve been exploring some of the processes and procedures we’ve put into place here at Brightec to aid our development and project management. This is the final post in this series - ‘Evolving the Dev Process’.
This final post in the series focuses on our git branching strategy.
A good branching strategy
We follow a popular strategy commonly used by a number of other organisations. A great visualisation can be found here.
A good branching strategy should be simple and easy to understand. You should be easily able to identify which branch contains which features. Also, it should be flexible enough to cope with agile workflows and quick releases.
As a developer I should be able to work on the next release, whilst other team members are prepping the current release in another ‘safe’ tested branch.
We have four kinds of branches:
- Master (what’s in the app store)
- Release (the next major release)
- Dev (Work in Progress for next major release)
- Feature branches (correspond to Jira Tickets)
The Dev and Master branches last forever, the others are transient. New stories are worked on in the feature branches off of Dev.
Dev will always contain all the new features we are working on for the next release. If we are already about to release, we would use a release branch. For example - 2.1-release and a dev branch Dev which contains tickets for the 2.2 release.
The release branch allows us to cherry pick what will be included, bug fix, test and stabilize. Fixes in release can be pulled into dev. When a release is production ready, it will be merged into master and tagged.
Here are some of the naming conventions we use:
- Master - Master Branch
- Dev - Dev Branch
- X.X-release - Release Branch
- LCA_000 - Feature Branch (named after Jira ticket)
We are starting work on the next release 2.1. Here is a rough outline of the branching strategy we will most likely follow:
- As a developer I will take my Jira tickets and create a branch from the Dev branch, this branch could be called LCA_562
- I finished work on the branch, squash commits, and pull request to dev branch
- Code review is successful, so I merge into the dev branch
- Deadline for 2.1 is looming, we’ve finished development, we create branch release_2.1 from Dev and set version numbers, release params etc
- We send 2.1 off for testing
- A few bug fixes are required, create another feature branch LCA_333 for example, fix the bug, pull request and merge back in
- We then code freeze 2.1, merge into master and release
- Master is tagged with release_2.1 and we may end up branching for any last minute hotfixes
Done! Hopefully this post and the others in this series will have you helped improve your dev skills and productivity.
Evolving the dev process
This article was originally written for Brightec by Seren Matthews