Branching code is a bit of a pain. And agile teams need to do more of it typically. This is because we are balancing new features with production bug fixes, and working in short scrum sprints while also keeping an eye on longer term visions for our product.
As an agile coach, I am often asked by development teams what is the best way to branch their code once they switch to scrum. In this video, I will walk you through it a couple of recommendations.
Here is a summary of the strategies mentioned in the video. If the graphics below are confusing, then definitely go back and watch that part of the video because I walk through each part of the picture one piece at a time and explain the flow.
Branching by Feature
In this method, you make a separate branch for every new feature that you work on. This is a very simple and flexible method because you can choose which features to deploy, one by one, after they have been tested. It works best if your new features can be developed independent of one another. This method will come more naturally to teams following a Kanban style process since it supports single-piece flow very well.
Branching by Sprint
This method is more complex, but provide a lot of power to Scrum teams which prefer to work on multiple features at once during a sprint. The assumption here is that you will release to production after every sprint ideally. User stories that the team plans to release at the end of the sprint are worked on in the current sprint’s branch (ie, «sprint_x»).
User stories that are part of a larger epic, and will not be deployed to production for several sprints, are worked on in the «epic» branch. It’s important that after each sprint is deployed to production, the sprint’s branch needs to be merged back up into the epic branch so that work done on epic-related user stories is integrated frequently with the latest code.
Separate branches are maintained for the testing and production environments so that you always have a place that mirrors the code deployed to those areas.
Branching for hot fixes to production
A «hot fix» is when you have a critical bug in production that must be dealt with now. Bugs which are not a huge crisis should be dealt with as part of normal sprints and their associated releases.
Occasionally though (and this should be rare), you will have a big bug that must be dealt with now. In those cases, branch from the testing or production branches, and make a new branch dedicated just to that hot fix. Merge back to testing or production and deploy it as soon as it is tested. Don’t intermingle these with any other new code being worked on for the sprint or epic.
After a hot fix has been deployed to production, it’s important that you merge the changes back out to the other branches too, so that the master, sprint, and epic branches will all be up to date and your changes cannot be lost by mistake.
How do you like to branch code?
These are some strategies that have worked well for AgilityFeat development teams, and for some of the clients that I coach on agile methods. But it’s not the only solution of course, nor are these solutions unique to us at AgilityFeat. How do your agile teams deal with branching? I’d love to hear your feedback on Twitter or by email (my first name Arin at agilityfeat.com).
Comentarios recientes