Serving a Single Master

As our organization evolves, the static nature of some of our tried and trusted processes can result in conflict between where we are as a company and how productive our processes enable us to be. One area that our Tech team recently decided to reexamine was our process for deploys.

Our Systems Development team is divided into smaller initiative teams, which are dedicated to serving business needs. For a long time we used Vincent Driessen’s gitflow as our git branching strategy in order to keep our work separate and contained. As the number of developers in our repository increased, what once worked well for us started to show its shortcomings. As we approached the development of our ERP, our velocity began to increase exponentially, and our once reliable gitflow became at best an inconvenience—at worst a painful blocker to productivity and functional code.



The gitflow process had several major issues, all related to the way our team conducted and pushed work. In previous projects under gitflow, we had multiple groups of both internal and third-party developers working on many long-lived feature branches. Upon completion, we would have to merge back into the singular develop branch, which would often bring numerous conflicts and bugs, as well as improper implementation and missing features.

This process also required increased testing efforts; we would test a feature within its branch as well as after merging. If a merged feature branch affected the behavior of existing code or code from other branches, we would have to circle back with stakeholders to discuss how to manage this issue; one which we discovered much later in the process than we would have liked to.

In essence, with the various teams operating at their own cadence, business deadlines, and other factors, our newfound velocity was at risk due to a branching strategy that had too much management overhead.

Our solution was for each team to work directly on a single mainline branch. This allowed us to get back into alignment and fully utilize our continuous integration tools. This resulted in:

  • The units of work being integrated were more digestible (individual commits)
  • Smaller and more frequent integration of units of work, resulting in testing performed in less time and on a more regular basis
  • Improper implementation and other course correction measures could be determined and applied more rapidly
  • Less likely to duplicate needed functionality by different developers
  • Better awareness of what other teams were working on
  • Naturally evolved self-governance among teams when necessary

We made adjustments to our deploy process to allow deploys that included incomplete features, and eventually adopted this methodology to all of our repositories. By working in master, we encounter problems sooner, experience fewer merge conflicts, and have better awareness of what other teams are working on.

Posted Under:

Posted on