Why I Migrated the Team from gitflow to SkullCandy

If you ever wondered the benefits of migrating your team from gitflow to SkullCandy, this article will cover why I did the migration and results I saw.

I review how we were using gitflow, its pains, and why I chose SkullCandy. I also discuss results from using it over a year.

This will give you an inside look into the whys and results of changing the team’s code workflow.

This article will take you less than four minutes to read.

Introduction

One of the engineering goals set for me in 2018 was to increase the number of deploys to production. As part of the engineering team leads, we brain stormed and identified an area that was the source of this problem:

Our git workflow inhibits us from deploying frequently

How can that be?? gitflow is the most popular workflow!

gitflow

At the time, the team used gitflow, the most popular branching model with git.

There are three branches with gitflow and this is how changes and deploy happen with our team:

Cutting Release Branch

Periodically, there’s a “cutting release branch” event, which moves changes from the develop branch to release branch. The goal of this event is to signal:

• testing moves to the staging environment
• changes can still happen to the develop branch
• new changes need to goto the release branch
• ultimately: get the application ready for production deploy

The thing about cutting the release branch, it may not be in a deployable state as the develop branch may contain code that is not supposed to be part of the next release and/or not fully tested/vetted.

The deployability of the release branch depends on when we cut the release branch.

Ensuring Release is Deployable?

How can we ensure the release branch is always in a deployable state?

• only cut when the sprint finishes
  • this requires the team to be on a clean sprint (and stick to it!)
• only merge code into develop when it’s perfect
  • this is ideal, does it ever happen in practice?
• ???

In our company there are different teams and within the teams, people move at different velocities with respect to their code. There are people variables to account for, not just code!

In terms of another goal for the code workflow, we wanted to still utilize integration/staging environments as a safety check and CD/CI systems uses specific those branch names for deploy.

How can we account for all of these?

SkullCandy - the git workflow

In researching different git workflows, I found a list in this article that gives overview of gitflow and others.

The one that stuck out to me was SkullCandy (the headphone company?!)

The nice thing is that SkullCandy uses branches master and develop, making it compatible with our CD/CI system. There is no release branch, just master.

How each changes goto branches and destination for deploys:

SkullCandy Branches

The branching in SkullCandy treats master as the source of truth:

• master is always deployable
• master can overwrite develop at any time
• master requires changes made to it for staging/production deploy
• develop can have changes made to it for integration deploy

In this way, there is no question where production code is ultimately: master branch.

SkullCandy Developer Workflow

With the SkullCandy branches, these are the steps for new code changes:

1. Make new changes against the develop branch
2. Get changes signed off by team
3. When ready, make change against master branch
4. goto 1.

With the branches, the code still show up on the same integration and staging environments as gitflow. To the CI/CD systems, they are the same. There is one extra step in recreating the work.

Workflow Friction

The friction in SkullCandy’s git workflow that is not in gitflow is step #3, where the developer needs to make the same change against the master branch as develop. This is essentially, duplicating work!

This is a duplication of work, with git cherry-pick this is little effort. I also see the benefit of this friction as only the code changes ready for production is in the master branch. The author is making a strong intent on deploying the code, not waiting for “cutting the release branch”.

Also, with this additional friction, each developer’s knowledge of git needs to be more than just: git add/commit/push.

What’s the Result?

After ironing out the team’s migration to this workflow and stepping back, these are the results I see:

• The system is able to deploy as frequently as everyone signs off on code changes to production.
• We can deploy code with confidence as contributors consciously made another commit to put into the master branch.
• We deployed more frequently - from once a month to multiple times per week. (Even on Fridays!)
• We have decoupled deployment from the sprint. We can deploy in the middle or end of the sprint and we will have the same confidence in the code.
• Develop/Integration environments match production environment as we create develop from master.
• Code in master branch is the final solution. All mistakes found in integration environment are all packaged together into a single change.
• The master branch is composed of the changes by its authors.

Conclusion

After having the team work with SkullCandy git workflow for over two years now, I don’t miss gitflow at all. For me, the benefits of SkullCandy outweight the benefits of gitflow.

Taking different approaches to how the team works with code brings different benefits and worries. I don’t worry about “cutting the release branch” anymore. I spend my time making sure the team is putting out the best code and what gets into production is their best work, even when they started with quick & dirty.

In another post, I will share how I got the team off of gitflow and onto SkullCandy git workflow (and tips on how you can make your transition easier!)

Want to talk about code workflows more? Contact me!

If you got this far and wondered how I migrated the team, here’s the article