Continuous integration (CI) is a spectrum
Continuous integration (CI) is a spectrum.
The question is, how frequently should we integrate our code changes?
Options from most to least continuous:
1. Commit to trunk the moment a small change compiles and all tests pass locally. Use feature flags to hide incomplete work. No branch. No review.
2. Commit to trunk when the feature is done and all tests pass locally. No branch. No review.
3. Create a short-lived feature branch. Merge when feature is complete and CI build passes. No review. Goal: Merge daily.
4. Create a feature branch. Open a PR when done. Merge when PR is approved and CI build passes. Goal: Merge daily.
Option 4 is the most common.
But, some CI “purists” argue options 1-3 are “true” CI, because they integrate changes more often.
Option 4 is popular for a reason.
With option 4, we integrate our changes often enough that merge conflicts aren’t a big pain point. We can still deliver features daily. And we avoid the risks of committing directly to trunk.
It’s a nice “sweet spot”. 👍