We follow many agile processes, including automated tests, continuous integration, sprint reviews, etc… We’re currently having a debate about how often we should branch release builds.
We’ve been doing two-week sprints and trying to deploy to production at the end of each sprint. Some of us think we should be branching every sprint. Some of us think that’s overkill. If a project encompasses three Visual Studio solutions, and we branch every sprint, then that’s three branches, and three CI builds to create every two weeks. If we do this for six months, we’ll end up with 36 branches and 36 CI builds. There is overhead involved in that.
For those of us that think that branching every sprint is overkill, we don’t have a very good alternative. On my last project, we deployed some solutions from the Main trunk. Yeah, that’s not good, but it saved on some of the overhead.
What’s the right way to manage branching/releasing and CI builds, using agile, when we have such short (two-week) sprint cycles?
As long as you tag each release you don’t need to branch. The only time you need to branch is when you need to apply a hotfix to a previous release and you cannot just upgrade your customers to latest. If you need to go back to a previous version and patch it, you branch off the tag/label.
I would read A successful Git branching model
You need to branch when you want to continue putting in new features but not give them as a patch to a previous version. What is their reasoning to create a branch every spring?
It is a good idea to create a tag for each release. If you have three solutions that are released separately then that would mean three tags, I see no problem with that. Does each release have to have it’s own build configuration on the CI server? It depends on how many versions you have to support. If you only need to support latest release, while working on a new one, you could get away with minimum of two build configurations: one that builds whenever changes are made to the trunk, one that builds the latest release.