Continuous Integration Fundamentals: CNPA practice questions

Continuous integration is the practice of integrating every developer's work into the shared main line of the code base frequently and checking each change automatically. DORA's description of CI starts from the problem it solves: in a system many people change at once, a small change in one file can break something elsewhere, and changes from different developers can be incompatible. CI follows the principle that if something takes a lot of time and energy you should do it more often, which forces you to make it less painful, and it relies on fast feedback loops and small batches of work.

DORA lists the key elements simply. Each commit should trigger a build of the software. Each commit should trigger a series of automated tests that give feedback within a few minutes. To make that work a team needs an automated build process that produces packages which can be deployed to any environment, are numbered and repeatable, and are treated as the authoritative output used by every later stage; a reliable suite of automated tests, starting with a handful of unit and acceptance tests that cover high-value functionality; and a CI system that runs the build and tests on every check-in and makes the status visible to the team.

CI as defined by Kent Beck and the Extreme Programming community also includes two practices that DORA finds predictive of higher delivery performance. The first is trunk-based development: developers work in small batches and merge into trunk at least daily instead of keeping long-lived feature branches. DORA's page on trunk-based development calls it a required practice for CI and describes branches that typically last no more than a few hours. The second is the agreement that when the build breaks, fixing it takes priority over any other work.

For a platform team, CI is one of the first capabilities users ask for. Offering it well means shared runners, reusable pipeline definitions, caching that keeps feedback fast, and clear output when something fails; DORA's platform research found clear feedback on the outcome of a task to be the capability most correlated with a positive user experience.

Several misconceptions come up. Running a CI server is not the same as practicing CI: if developers merge only once a week from long-lived branches, the server just reports late, large failures. Flaky tests are not harmless; DORA stresses that tests must be reliable, so that a failure means a real problem and a pass gives confidence. Slow suites undermine the practice too, because developers stop running tests they have to wait for, and failures become hard to attribute when many changes land between runs. And CI is not deployment: it produces a tested artifact, and continuous delivery is what takes that artifact to environments.

At associate level, expect questions on what should trigger a build, how often to merge, what to do when the build is red, why the build output should be the artifact deployed everywhere, and how trunk-based development differs from feature-branch workflows.