👋 Hello, this is Valentina with the free edition of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.
Most teams do the opposite.
Pain → delay → bigger merge → more pain.
That is the system.
“We’ll merge when it’s done”
Because:
merge is painful
integration is slow
system breaks in unexpected ways
What teams do next:
❌ integrate less often
❌ delay merging
Wrong.
1. Integrate into main frequently
Not “eventually”. Not “when finished”.
✔ multiple times per day (or at least daily)
✔ small changes only
❌ no “feature branch for 2 weeks”
❌ no “merge at the end of development”
2. Every integration triggers a system check
When code is merged (or proposed for merge), the system must verify:
✔ compilation works
✔ unit tests pass
✔ component tests pass
✔ system tests pass
Not “some tests”.
The goal is:
do the components work in isolation? AND
does the system still work as a whole?
Note: quick verification (compilation, unit tests & component tests) is triggered on merge, whereas slower verification (system tests) are triggered on an interval-based schedule.
3. Broken main is not allowed to persist
This is the most important rule in real CI.
✔ if main breaks → fix immediately
✔ nobody continues building on a broken state
✔ the team treats main as always releasable
❌ “we’ll fix it later”
❌ “let’s ignore it and keep going”
4. Changes are small by design
CI only works if changes stay small.
small commits
small merges
easy rollback
Because:
❌ large batches hide integration problems
✔ small batches expose them immediately
5. Integration problems are found immediately, not later
CI is basically: shorten the time between “change” and “system feedback”
So instead of:
❌ change → days later → production breaks
You get:
✔ change → minutes later → system check fails
6. The system is always in a working state
This is the outcome CI is trying to enforce.
✔ main branch always works
✔ every change is either:
integrated and working
or not integrated at all
❌ no “half-working shared state”
What CI/CD is NOT (important)
❌ running Jenkins
❌ having a pipeline
❌ building artifacts
❌ running tests once per day
❌ merging occasionally
Those are tools or schedules.
Not CI/CD.
✅ A Real Pipeline = Continuous Delivery
👉 I’m running a live workshop where we walk through a working e-shop example with a pipeline architecture, so you can see how it works in practice.
No rebuild tricks. No “it passed CI but broke anyway” surprises.
€100 off with code EARLYBIRD100 — limited spots.
Larger change -> harder merges -> more pain.