Git flow is awesome, and accomplishes everything you might want easily.

This is (part) of an email I sent out today about the patterns git flow sets you up for, and what that means.

The Broken Build

> Hi guys, > > Can you guys huddle and see about getting the build working again? > > Thanks! > - Ed The Manager

My Response

I think it’s important to use this time to highlight that most of the work happens in the “develop” branch in Github. There’s another branch, “master” that is synced up with the latest when [redacted] does a release.

Master is what (everything sometimes integration) gets their code from

Take Home Point

Even if the build is broken on the develop branch [ed: which is what the original email was referring to], we’ll always have a production ready build (on master).

Changes when the build is broken (for production)

If we absolutely must make a production change while the develop build is broken, that’s also possible with our process and this “git flow” tool we use. (we do our work and put it on master, not on develop).

BUT if we release when we have a broken build, we: (a) We lose that “know good” state we can make critical fixes.

(b) possibly introduce bugs (that the tests are trying to point out to us)

In Production

The coming pressure of “a bug in production” will also try to force the “release this branch now, broken build or not!” Again: we have process for that (production critical bugs should happen as what git flow calls “hotfixes”

The point: if we as a whole Agile team, don’t release (putting the develop branch into the master branch) when the build is broken, we’ll always have a “known good” point we can issue emergency hotfixes for production issues.

And we can deploy this “master with this new hotfix” and start the deployment process with them.

Too Long; Didn’t Read

The develop build could stay broken for days, and it doesn’t matter, with the pattern we are using. Production fixes can go in and the client will see responsiveness.

The master build, yes, the concerned stakeholders should/could watch to remain informed of the state of the production-ready code. Broken builds here are “drop everything” critical issues.

Hope this explains our process, and how we can accomplish change even if we’re waiting on the build to be fixed elsewhere.

Conclusion

Git flow is a standard tool at Wilcox Development Solutions. We love that it enables developer productivity and forward motion, while enabling being responsive to the customer on critical issues.

While having a broken develop build is bad, and should be fixed, ideally the team itself should manage itself in this way (via peer pressure and professionalism), instead of this being a critical management issue. Because management has other things to worry about.