Continuous Integration or Continuous Isolation?

Developers often complain about the risks of merge conflicts with long-lived branches, but the “solutions” they propose usually miss the real point. The most common one is to keep merging main (or, even worse, develop) into the branch.

That’s often accompanied by the vaguest advice of all: “Keep communicating with others to know what they’re working on.”

The first is a non-solution. Merging the main trunk of development into branches regularly doesn’t help when changes stay isolated on those branches for long periods. Other developers’ work won’t land in main quickly enough to reveal integration issues in time.

The second is also a non-solution, and frankly a ridiculous one. First, it’s impossible to know at any given moment what everyone else is doing and to work around it. That approach simply doesn’t scale. Second, if we need to invest that much energy into constant communication, it’s better to do it synchronously by working socially.

The real solution to this conundrum is called Continuous Integration.

Unfortunately, only a small fraction of developers know how to implement it well. The prerequisite for CI is trunk-based development.

My recipe:

• Adopt Trunk-based Development: code is integrated into the main line continuously (ideally every few minutes).

• Adopt Team-focused Development: social programming techniques like pair or mob, so code review happens continuously.

• Adopt Test-driven Development: the short feedback cycles make it possible to push code every few minutes with confidence.

• Embrace a Continuous Delivery model.

Yes, I think the solution is T*D.

Teams should ditch long-lived feature branches, post-development reviews and, above all, anti-CI models like GitFlow.

Originally posted on LinkedIn.