DevOps Stack Exchange is a question and answer site for software engineers working on automated testing, continuous delivery, service integration and monitoring, and building SDLC infrastructure. It only takes a minute to sign up.
Sign up to join this community
Should I use a release branch to push changes out to production or release it off master branch - the main pipeline where changes are merged by developers of their feature branches?
Not to mention, there is still some amount of manual testing and that happens on the master branch after developer has completed the changes in feature branch and automation testing, code review is completed and changes are merged to master.
What is the recommended practice?
What is the recommended practice?
The book ”Accelerate” by Forsgen, Humble and Kim documents their research that teams that use fewer long-lived branches are more successful.
The question is then what is the best minimum set of branches for a given team. The answer to that, like many things, is ”it depends”. A team that pushes into production a dozen times a day will prefer tag then release from master. A team that releases once a sprint into an integration test environment for a week before it goes live will generally prefer two branches.
Should I use a release branch to push changes out to production or release it off master branch
My personal experience is that adding branches later if you need them is easy but removing branches is very hard. So given that we want to minimise the number of branches I recommend that small teams who release often always release from a tag applied to master. It's very easy to create a branch from the tag that was last put live if you do need to create a short-live patch release branch. The point is that you want that to be the exception not the rule give the research in the book named above.
I have seen many teams use a two branch approach. To common ones are:
These approaches are actually identical. The reason to take this “two branches” approach is so that features can be released independently and reordered.
Not to mention, there is still some amount of manual testing and that happens on the master branch after developer has completed the changes in feature branch and automation testing, code review is completed and changes are merged to master.
There isn’t really enough information in your question about how your team actually works to know whether a one or two branch strategy would be a good fit. Your actual release, testing and support ways-of-working dictate the best strategy for your team.
A common practice is to build and test off of a pull request to master. Your developers create feature branches, and submit a pull request to master when it is complete. This then triggers a build job based on the PR.
For example, if you are using Github and Jenkins, you could use the Github pull request plugin to run a Jenkins job when a PR is submitted to master. If it passes, then perform your code review and manual testing.
It depends on what do you want/expect from your release strategy.
Since you're at peace with using feature branches, it means you're also at peace with potentially complicated branch merges and the risks they bring into your master branch: breakages, delays, etc.
If you have strict release deadlines you'll have a hard time meeting them directly from master, pulling release branches off master after the needed feature branches are merged will give you a chance to stabilize the release codebase by isolating it from changes for future releases which I presume continue to be merged into master. The smaller changes with a lower commit rate should significantly lower the risks compared with the master branch.
Release branches also allow you to provide to your customers release hot fixes and complex release stories: multiple simultaneously supported releases, major/minor/incremental releases, etc. It would be very difficult if not impossible to achieve these while releasing directly from master.
The drawbacks of using release branches:
If the advantages the release branches offer are of no interest or if their disadvantages are show-stoppers for you and you're fine with an "as-is/take it or leave it" basis for your releases then just use selected master branch refpoints for release candidates and, if they meet your release quality criteria, tag them as releases. If after that any issue is being found with a release - just wait for a subsequent release with the fix (but it may contain other stuff as well).
The major disadvantage of this approach is the difficulty of picking your release candidates in full flow of changes going into master (drinking from the fire hose?). The chances of finding good candidates can be pretty low. What if you don't find any? Attempting to throttle the rate of commits going into master in an effort to stabilize it prior to a release will translate into delayed integration (features staying in their dev branch silos longer than absolutely needed), increasingly complicated branch merges, which will eventually cause compounding delays/slips in all your future releases.
Up to you to chose the lesser evil. This is why I'm a fan of continuous integration - at least the complicated merges are out of the picture. The release strategy considerations still apply with CI - the release strategy kicks in after the integration is done - but the 2 evils are "less bad" :) From my experience significantly less. And with a gating CI system in place it's possible to keep master stable regardless of the commit rate.
