Continuous Integration Pipelines Overview: CNPA practice questions

A CI pipeline is the automated sequence of steps a change goes through after it is pushed: fetch the source, build, test, analyze, package and publish an artifact. Where the continuous integration practice is about how developers work, the pipeline is the machinery that makes that practice cheap enough to run on every commit. In platform terms it belongs to the white paper's capability domain of automation for building and testing products, whose example CNCF and CDF projects are Tekton, Jenkins, Buildpacks, ko and Carvel.

A typical pipeline has a few recognizable stages. A trigger, usually a push or pull request event, starts it. A build stage compiles code and produces a package, which for cloud-native services is usually a container image. Test stages run fast unit tests and then slower integration or acceptance tests. Analysis stages scan code, dependencies and images for vulnerabilities and policy violations. A publish stage pushes the versioned artifact to an artifact repository or container registry. DORA's guidance says the packages a CI build creates should be authoritative, numbered and repeatable, and its deployment automation guidance says later stages should download those packages from an artifact repository instead of producing new ones.

Pipelines are increasingly defined as code in the same repository as the application, which puts changes to the pipeline through the same review and history as changes to the code. Platform teams go one step further and offer pipeline templates. The CNCF Platforms White Paper's example of a golden path is exactly this: a reusable supply chain workflow for building, scanning, testing, deploying and observing a web application on Kubernetes, offered with an initial project template and documentation. Teams get a working, compliant pipeline on the first day and can still extend it, which is what the white paper means by optional and composable.

Speed is a design requirement. DORA notes that tests which take too long are run less often, that failures are then harder to trace to a single change, and that the build status should be visible to the team, preferably through a chat system rather than email notifications that people filter away. Pipelines also need to be reproducible, so the same commit should produce the same artifact; that is why builds pin tool and base image versions.

Misconceptions to avoid: rebuilding the artifact separately for each environment, since it should be built once and promoted; letting a pipeline grow until feedback takes so long that developers stop waiting for it; and treating the pipeline as owned by nobody. When a shared pipeline template breaks it breaks for every team using it, so the platform team has to version and operate it like any other capability.

Exam-style questions here usually ask about the order and purpose of stages, where artifacts should be stored, what a golden-path pipeline gives a team, or how to shorten feedback time.