Key practice in effective product development culture.
—
From long-lived branches to continuous integration
Long-lived branches (AVOID)
Team members work on features on separate branches for extended periods of time (weeks and up). Once the feature is complete, they will attempt to merge the branch into the mainline. Long-lived branches tend to lead to what is known as “integration hell”.
Short-lived branches (BETTER)
Team members work on stories or tasks on separate branches for a few days at a time. Once the story/task is complete, they will attempt to merge the branch into the mainline. Short-lived branches will have less integration issues than long-lived branches.
Continuous Integration, Relentless Testing (BEST)
Team members work on stories or tasks and, once automated tests pass, merge into the mainline multiple times a day. In the oldest variant of this, all the tests needed to pass before the merge occurred. These days, it’s more typical to see stages. Pre-merge build verification tests, post-merge tests which may take longer.
Also known as:
- Trunk Based Development
- Mainline development
- Continuous merge
Continuous Deployment (aka continuous release)
Once acceptance tests pass, automatically deploy to production and release (aka expose) to customers.
Continuous Delivery (aka releasing-on-demand)
Once post-merge tests pass, automatically deploy to production but hide features behind feature flags so that we can choose when to release and expose new features to customers.
See also
- Ship / Show / Ask (martinfowler.com)
- Trunk Based Development: Introduction (trunkbaseddevelopment.com)
- Continuous Delivery vs Continuous Deployment — Crisp’s Blog (my diagrams are inspired by the ones here but updated for typical modern practice)
- Patterns for Managing Source Code Branches (martinfowler.com)
- Continuous Integration Certification (martinfowler.com)