Using this software on top of our branching strategy has really helped to streamline our processes, and react to, and manage client requests much more readily.
The key to branching
Having a truly flexible branching strategy seems to be one of the hardest things for any software development company to get completely right. It will be of no surprise to anyone that there are numerous suggested methods out there, each to try and alleviate a specific recurring problem that is faced as part of the software development lifecycle.
What is branching (version control)?
Branching is the concept of having a single code base or solution, of which copies are made to allow for multiple lines of development to occur in parallel. The main code base representing the trunk of the tree and each separate line of development representing the branches of the tree. When a new feature is requested by the client, a bug has been found and requires a hotfix, or even just maintenance work is required, a branch is taken from the main code base to work on allowing the developer/team the opportunity to work independently from any other work ongoing on the solution. Once the work has been completed and tested, it gets merged back into the main solution and forms a new part of the main code base.
The agility in branching
If all development tasks were to occur sequentially during the process, then there would be no need for a branching, and you could just work on the main solution. However, this is very rarely a real-world scenario. Unforeseen circumstances such as bugs, the client changing their mind on a feature or requesting a new feature, issues with hosting or the servers etc. can all play a part in muddying the waters and making this process a challenge to keep precise, reduce the amount of rework needed, and minimise effort required to keep the main code base an accurate representation of the current live software.
The scenarios
Here are just two example scenarios which we face regularly:
Scenario 1
A feature branch is merged back into the main code base ready for release after testing, which then is unable to progress to live as a bug has been found or hasn’t been addressed in the new feature branch. This now holds up any other pieces of work ready to be released, and requires either a fix to the problem to be found quickly, or the whole main code base must be reset back to before the feature was merged into the main solution.
Scenario 2
A feature branch is merged back into the main code base, but the client has decided that a new feature takes priority over the work about to go live, and so the feature branch must be removed from the main solution to allow for this new feature to be implemented.
How to use branching
This is where things get a bit more complicated, and so I will describe the current strategy that the team I’m a member of here at Equator are employing to make this process as flexible and easy to maintain as possible. Just to note, we use Git, however this is merely just an abstract concept, and so, so long as your Source Control software allows for branching, (which it really should) then this should be applicable to any scenario.
The process
This process has 5 different branch types:
Feature branch
Development branch
Release branch
Hotfix branch
Master branch
The process explained
Everyone has a different name for what the branch which represents the main code base is. Whether that be Master, Live, Production, Origin, Source, etc., this is the core of the solution. We tend to use Master or Live. This always represents what is currently deployed on the live site.
It is from here that we take our Feature branches to work on and implement any new requests from the client. Once we have all the features which are requested, merged back to the Development branch, completed, and tested, we branch from the Develop branch again and form our Release branch. This now frees up the Develop branch for the next round of features to be completed.
The process continued
Only once the client has fully tested and signed off on the work on the Release branch, do we then merge this Release branch into the Master branch and deploy that to the Live site. To handle any issues which are found on the live site, we also have the concept of a hotfix branch.
This is a branch which is taken from the Master branch, the fix to the bug identified and implemented, and then merged back into the Master branch and deployed to the live site. It is also merged back into the Develop branch, and if applicable, any pending release branches. This keeps everything coordinated. These levels between our Master branch and Feature branches allows us to be more flexible and react to and handle the changes to the lifecycle much better.
Visualise the process
If any of this is too wordy and doesn’t make much sense, here is a little diagram which should help to visualise the process better.
Implementation
As a company we use Atlassian software (JIRA, SourceTree, BitBucket, Confluence), which integrates all of our processes well. We can create our branches from JIRA tickets and use “Smart Commits” to give us, and our management team better visibility of the work being carried out. We can more accurately log our time spend on each task, and keep track of completed work and bundle it into releases all within JIRA and SourceTree.