Dzero Labs
Published in

Dzero Labs

Go Fork Yourself

My rubber chicken is horrified by bad Git practices
  • Creating aliases to make Git work like your old VCS.
  • Storing build artifacts in Git (it was considered okay to do this in ClearCase, for example).
  • Non-Git branching strategies
  • Cherry-picking as part of your workflow
  • Accidentally merging code into the wrong branch, therefore breaking code
  • Cherry-picking code from a bunch of branches into a release branch. This is a nightmarish task that often requires a team of Git pros to do this, and which is the equivalent of picking all the red M&Ms from a large jar full of M&Ms. Not fun.
Screen capture of an organization’s total bungle of Git branching. These are all long-lived branches.

Fork is a 4-letter word

Ephemeral Release Forking Model
  1. It minimizes the number of branches being worked on at any team
  2. It prevents teams working on different releases from accidentally mucking up each other’s code

How Ephemeral Release Forking Works

  • The fork is named after golden repo and the major release #. For example: MySuperApp-2.0.0, or MySuperApp-3.0.0.
  • If you’re creating a hotfix off of the current 1.x prod code, you create a hotfix fork named MySuperApp-1.0.0
  • When they are ready to integrate their code, the developer submits a pull request to their team lead, and once approved, the code is merged into the develop branch.
  • Specifically, the artifact is published into the Snapshots Repo.
  • The package version is bumped each time a new package is published to Snapshots. For example, in the MySuperApp-1.0.0, artifacts published to snapshots might be called MySuperApp-1.2.0, MySuperApp-1.3.2, etc. The major version stays the same, because all work is being done off the 1.x fork.
  • There is one CI pipeline per fork.
  • The package is ready to be deployed to QA, and can be tested ad nauseum (hopefully via automated QA tests).
  • Any bugs identified means that it goes back to developers, and then repeat Steps 4 onward
  • Packagers in the Releases Repo are ready for Production!
  • Remember how we enabled fork syncing in Step 2? In doing so, it ensures that any code merged to master in the Golden Repo is automagically propagated through to the master branch in the forked repos. This means that hotfix code is automagically propagated to any teams currently working on a release in their own forks.
  • Our release has made it into prod, so we don’t need it anymore
  • Because our code is in the Golden Repo and has been tagged, we can always create a new fork to work on any hot fixes

Additional goodies:

  • Just because the code is automagically in the fork’s master doesn’t mean that it automagically makes its way to develop. The team lead must always merge code in the fork from master to develop at least once a day to ensure that the fork has the latest and greatest prod code
  • There might be two teams working on two overlapping releases simultaneously, so how do you ensure that the team working on Release 3 gets some of the goodies being worked on in Release 2? Via pull requests!

Does this work?

Further Reading

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Adri Villela

I push the boundaries of software delivery by learning from smart people who challenge the status quo | Former corporate 🤖 | On-Call Me Maybe Podcast co-host