This is a list of points in support of trunk-based development and its related practices.

  • Continuous Delivery includes using Trunk-based Development and Continuous Integration. (Forsgren, 2018).
  • Continuous Delivery “predicts lower change failure rates, which is an important quality metric.” (Forsgren, 2018)
  • Continuous Delivery “predicts lower levels of unplanned work and rework,” which are both “useful proxies for quality.” (Forsgren, 2018)
  • Continuous Delivery leads to reduced deployment risk, believable progress, and user feedback. (Fowler, 2013)
  • Trunk-based development is a type of continuous integration, which is a “first step towards continuous delivery.” (Forsgren, 2018)
  • Trunk-based development is also related to a Light-Weight Change Management Process, which leads to faster delivery and increased software stability: “approval by an external body (such as a manager or CAB) simply doesn’t work to increase the stability of production systems... [though] it certainly slows things down. It is, in fact, worse than having no change approval process at all.”
  • Trunk-based Development reduces micromanagement and possibility for office politics. (Gadzinowski, n.d.)
  • The practices surrounding Trunk-based Deployment decrease burnout (Forsgren, 2018)
  • Trunk-based Development is how StackOverflow does deployment and, “almost all commits are directly on master.”  (Craver, 2016)
  • For one review of the publications and practices in support of and against Trunk Based Development see Paul Hammat (2018) which ends stating that both Google and Microsoft practices reinforce Trunk Based Development.  

Trunk-based Development Practices

  • Trunk-base Development involves, “developing off trunk/master... branches that live a short amount of time (integration times less than a day) combined with short merging and integration periods (less than a day).” (Forsgren, 2018)
  • Continuous Integration "is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day.” (Fowler, 2006)
  • Time otherwise spent on manual processes such as branch management goes toward automated quality control processes (unit tests, integration tests… linting, formatting) that are built into the deployment pipeline.
  • Trunk is always in a deployable state. When (not if) trunk breaks fixing it becomes the #1 priority.

References

Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The science behind DevOps : building and scaling high performing technology organizations.

Fowler, Martin (2006) Continuous Integration. https://martinfowler.com/articles/continuousIntegration.html  

Fowler, Martin (2013) Continuous Delivery. https://www.martinfowler.com/bliki/ContinuousDelivery.html  

Cochran, Tim (2020) Maximizing Developer Effectiveness. https://martinfowler.com/articles/developer-effectiveness.html (Comments on HN https://news.ycombinator.com/item?id=25789295)

Nick Craver (2106) StackOverflow: How We Do Deployment – 2016 Editition - Branches https://nickcraver.com/blog/2016/05/03/stack-overflow-how-we-do-deployment-2016-edition/#branches  

Paul Hammat (2018), Game Changers, https://trunkbaseddevelopment.com/game-changers/

Konrad Gadzinowski (n.d.) Git Flow vs Trunk Based Development, https://www.toptal.com/software/trunk-based-development-git-flow