The clocks ticking, you cut release branch 1.2 from develop knowing that it will need to be regression tested and bug fixes will have to come in before you can do your monthly release over the weekend. You hustle to feature flag whatever features that are hiding in develop unfinished that could cause breakage in your production app. Depending on how much automated testing you have, this process could be somewhat quick, but for those that aren't as fortunate it seems on average it would take about a week.

The weekend comes, not everything is automated in your CI/CD process so you have to remind yourself what the steps are in order to do a deploy as well as what needs to be checked after the deploy since there were numerous features in your release branch.

The deploy goes out, it seems everything was successful, but wait! Feature 10 isn't working quite right and it seems that it is because we forgot to run a seed script needed for it to function properly. How did this happen? Everything was documented on what steps needed to be taken, lets see... Step 20, here it is run seed script 12 for lookup table categories. How did we miss seed script #12?!?

What do we do now? We release so infrequently that we don't even know the drill when something goes wrong. It takes hours maybe close to a day to resolve this issue due to our being rusty on the deploy process.

Now some may be saying to themselves that the answer to this problem is just to release more frequently, but is that easily done with Git Flow (or other similar branching strategies)? Depending on the size of your team and the rate at which you work (I've been on projects where build times and automated testing was enough to slow down releases) the frequency in which you can deploy to production is not often when you are trying to release so many features at once. Lets take a look at how git flow isn't conducive to an environment where you can release more frequently.

Release Branches

Is it just me, or is it crazy that we are cutting a release branch knowing that there will be issues in it that we will need to resolve. Knowing that we need to regression test the entire application in order for it to be deemed safe for a release to production. At a certain point, a release branch officially becomes what I hate the most, an environment based branch and can become very different from develop (which is also another nutty thing that we can consider develop our source of truth). On top of that, merging our release branches back to develop can be terrifying at times due to the fact that we are trying our best to remove or feature flag out features that were in develop and not done or ready for the current release. So often, I see changes that are dramatically different from a release branch than what was in develop.

Feature Flagging!?

C'mon guys (and gals), its 2019 and git is the de facto SCM tool, the fact that we are even considering feature flagging anything is a sign that we need to rethink how we are doing things. I'm sorry, but I can't get on board with the idea that I'm releasing something to production that might not work. There could be other reasons as to why you might want to implement a feature flag, which I'm sure could be justified, but for the most part it just points to the fact that the process needs to be revisited and that branching strategies like git flow cause the need for this.

There are a lot of things that could cause the need for feature flagging, but instead of going over them here, I'll point you to an article that illustrates them very well.

The Process

Git flow might start off as a very productive branching strategy, but over time it seems the process gets muddled. We stop thinking of features as something that can be deployed almost immediately (and should be deployed as quickly as possible) and start shoving everything into epics. We rely on the fact that we have release branches before features go out instead of just releasing the feature when its ready; on top of that, most of the time we have to wait for feature x to be done before feature y can go out because they live in the same release branch and if you mention feature flagging one of those features I'm going to lose it!

Planned releases just have a waterfall type feeling to me, call me crazy, but I want to have often unplanned releases and if your worried about what might happen in this scenario I recommend this great instructional video done by group x:

Enter GitHub Flow (Master Only)

Am I crazy? When mentioning deviating from git flow instead of getting sound arguments I would just get an appeal to authority and well... what do you say to that?!

Well now an authority does use master only, and for all of you Microsoft haters out there, they started doing it before they were bought by the tech giant. Does that change the fact that master only was always a good strategy? No of course not! In fact, git was created with this strategy in mind! I believe there were a lot of reasons why git flow was adopted, one of which was the inability to easily spin up sites per feature branch in the past and properly test them individually. Now that we have PAAS and Docker, what is really stopping us from adopting a master only branching strategy?

Did you read GitHub's explanation of master only? Really simple right? You have one source of truth, master. When you need a feature created you branch off of master, test that feature in its own branch, merge to master and deploy!!!! No more annoying merge conflicts merging 1.2.2 to 1.2.1 to 1.2 to develop, no more long release cycles, no more feature flagging!

I've done master only on both small and large teams and it was always a very simple effective strategy that helped us to release often and avoid really silly merge conflicts. I understand that every team and/or project is different and maybe master only isn't the right strategy for you, but before we make another appeal to authority as a reason to stick with git flow (or not go with master only) lets take a leap of certainty and switch to GitHub Flow!