Key Practice: Continuous Integration / Continuous Delivery

Jason Yip
2 min readSep 9, 2023

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”.

2 branches coming off the mainline that are long-lived (weeks, months). When they attempt to merge back to the mainline, there are significant issues aka integration hell.
Long-lived branches tend to lead to “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.

2 branches coming off the mainline that are short-lived (days). When they attempt to merge back to the mainline, there are less integrations issues than long-lived branches.
Short-lived branches tend to 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.

Merge changes when tests pass (minutes, hours)
Continuous integration AKA merging once automated tests pass

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.

5 stages with automatic transitions between each: Code done, pre-merge tests, integrate, post-merge tests, deploy to production, released to customers
Continuous deployment AKA continuous release

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.

5 stages: Code done, pre-merge tests, integrate, post-merge tests, deploy to production, released to customers. Automatic transition for all of them except releasing to customers which is manual via feature flag.
Continuous delivery AKA releasing-on-demand

See also

--

--

Jason Yip

Senior Manager Product Engineering at Grainger. Extreme Programming, Agile, Lean guy. Ex-Spotify, ex-ThoughtWorks, ex-CruiseControl