Describe Trunk-Based Development principles and CI/CD benefits

WHAT THIS TESTS: This question probes whether you understand Trunk-Based Development as a technical prerequisite for Continuous Integration and Continuous Delivery rather than just a stylistic preference. The interviewer wants to see that you can articulate the mechanics of a single trunk model, explain why long-lived branches create integration risk, and connect daily trunk commits to an always-releasable codebase. They are also checking if you know the safety techniques that make TBD viable at scale.

A GOOD ANSWER COVERS: First, define TBD as a model where all developers collaborate in a single branch called trunk or main and avoid long-lived development branches. Second, explain the commit frequency rule: developers integrate to trunk at least once every 24 hours, which satisfies the core requirement of CI and keeps the codebase releasable on demand. Third, describe the pre-integrate build practice where developers run compile, unit tests, and integration tests locally before pushing so the trunk never breaks. Fourth, mention that small teams may commit directly to trunk while scaled teams use short-lived feature branches lasting less than a day for code review and CI checks, but never for artifact publication. Fifth, name the two key techniques for larger changes: feature flags to hide incomplete work and branch by abstraction to refactor without long-lived branches. Sixth, connect this to CI/CD flow by noting that frequent integration eliminates merge hell, provides immediate feedback from the build server, and allows release branches to be cut from trunk just in time or skipped entirely with a fix forward strategy.

COMMON WRONG ANSWERS: A red flag is advocating for long-lived release branches or feature branches that persist for days without using feature flags or branch by abstraction. Another mistake is claiming TBD is only for small teams; the interviewer expects you to know that Google practices TBD with tens of thousands of developers in a single monorepo trunk. Saying that TBD means no branches at all is also incorrect because scaled TBD explicitly uses short-lived branches for review. Finally, confusing TBD with GitHub Flow without explaining the release-from-trunk distinction shows shallow understanding.

LIKELY FOLLOW-UPS: The interviewer may ask how you would migrate a team from GitFlow to TBD without stopping feature delivery. They might probe how feature flags are managed and retired. They could ask what build infrastructure is required, such as a build server verifying every commit to trunk. They may also ask how to handle urgent production patches under TBD, which is a good moment to mention releasing from trunk or cutting a short-lived release branch.

ONE CONCRETE EXAMPLE: Suppose a team currently uses GitFlow with develop and release branches that live for weeks. Under TBD, a developer working on a new payment API would create a short-lived branch from trunk, open a pull request within hours, and merge after green CI and peer review. The unfinished endpoint is guarded by a feature flag defaulting to off in production. The team runs pre-integrate builds on every workstation and uses a build server to validate each trunk commit. When the product owner wants to release, the team cuts a release branch from trunk, hardens it for a day, and deletes it after deployment instead of maintaining it indefinitely.