Eighteen-Day Feature Branches
Twelve developers on a Java service use GitFlow. Feature branches live 18 days on average, and develop is merged to main every six weeks at release time. The CI server builds every branch push, but the full suite takes 52 minutes, so developers run only unit tests locally and rely on CI for the rest. At the last release, integrating seven feature branches took four days of conflict resolution; afterwards main was red for three days. The suite holds 1,400 tests, 31% of which were flaky at least once in the last 90 days; the team has started re-running failures until they pass. Production deployment still requires a person to follow a 14-step manual checklist.
1. Which problems does the long-lived branching create here, and how does that relate to what continuous integration actually means? Distinguish running CI from doing CI.
Read the worked answer
Continuous integration means everyone integrates into trunk at least daily, every integration is verified automatically, and a failure is fixed immediately - you stop the line. Integration is a continuous activity, not an event.
Here, integration is a six-weekly event. Eighteen-day branches mean that what each developer believes is working code has never met anyone else's working code. The four days of conflict resolution is the deferred cost of that, paid all at once. The three red days on main are the second half of the failure: after the merge, the team does not stop and fix, it absorbs a multi-day broken trunk, which means nobody can trust the build and nobody integrates.
"Running CI" is having a server that compiles branches. The team does that. "Doing CI" requires short-lived branches, a verified trunk and a stop-the-line rule. The 52-minute suite and unit-tests-only locally explain why the fast feedback loop cannot exist yet: the verification step is too slow to be run per merge, so merges are deferred and batches grow.
2. Propose the changes in dependency order, and state the expected effect of each on integration time, red-main duration and MTTR.
Read the worked answer
Order matters, because each step enables the next.
Fix the test signal first. Split the suite into a fast commit stage of a few minutes and a slower stage; quarantine flaky tests with named owners. Without a trustworthy fast suite, every later step is unsafe.
Shorten branches. Move to trunk-based development with branches under a day, using feature flags for unfinished work. Effect: integration effort per merge collapses and the four-day conflict window disappears.
Gate merges on the fast suite plus review, with an explicit rule that a red trunk is the team's top priority. Effect: red-main duration drops from days to hours, because the change that broke it is small and obvious.
Automate the 14-step checklist into an idempotent deployment script. Effect: MTTR falls directly - restoring service stops depending on one person remembering step seven.
Then track the four DORA measures to confirm the direction rather than argue about it.
Steps 2 to 4 fail if step 1 is skipped: people will not merge daily into a trunk that cannot tell them whether they broke it.
3. What does the re-run-until-green habit do to the feedback signal, and how would you replace it?
Read the worked answer
Re-running until green converts the test suite from an oracle into a slot machine. Two things follow. Real failures get masked, because a genuine defect that fails one run in five looks exactly like flakiness. And the team's trust in the build drops, which quietly destroys the stop-the-line rule - you cannot ask people to halt everything for a red build they believe is noise.
The habit also hides the cost. Flaky tests are defects in test code, and every re-run buys temporary relief while the 31% figure stays the same or grows.
Replacement: route flaky tests into a quarantine lane that does not gate merges but is tracked; give every quarantined test an owner and a fix-or-delete deadline of one sprint; publish the flaky rate per test so it is visible rather than anecdotal; make "fixed a flaky test" a legitimate piece of work in the backlog. Then measure the flaky rate explicitly, because it is the leading indicator for whether the stop-the-line rule can ever be enforced.