CI/CD Relationship Fundamentals: CNPA practice questions

CI and CD are often written as one word, but they are two practices joined by a hand-off. Continuous integration ends with a tested, versioned artifact. Continuous delivery starts from that artifact and makes it possible to release it to any environment, on demand, at low risk. Understanding where one stops and the other starts is the point of this topic.

DORA describes what continuous delivery looks like in practice: the software is in a deployable state throughout its lifecycle, keeping it deployable takes priority over working on new features, fast feedback on quality and deployability is available to everyone on the team, and the system can be deployed to production or to end users at any time. CI is a prerequisite, because software cannot stay deployable while integration problems pile up on long-lived branches. DORA also separates continuous delivery from continuous deployment. Continuous deployment means trying to deploy every code change to production as soon as possible, which works for web services but cannot be applied to software such as firmware or mobile apps, whereas continuous delivery applies to all kinds of software, including highly regulated domains. Flux's glossary draws the same line, defining continuous deployment as automatically deploying code changes to production once they have passed automated testing.

The artifact is the contract between the two halves. DORA's deployment automation takes the packages created by CI, deployment scripts and environment-specific configuration as its inputs, and its guidance is to use the same packages and the same process for every environment. If an environment needs its own rebuild, what was tested is no longer what is released.

In cloud-native platforms the hand-off often goes through Git rather than through a direct call. In a push model the pipeline holds cluster credentials and runs the deployment itself. In a pull model, the GitOps approach, the pipeline's last step is to commit a new image tag or version to a configuration repository, and an agent inside the cluster pulls and applies it. The Argo CD documentation points out that with automated sync, CI/CD pipelines no longer need direct access to the Argo CD API server, because the pipeline only commits and pushes to the Git repository that is being tracked. Flux can make that commit itself through image updates to Git, delivering new releases to staging automatically while production version bumps go to a separate branch for a pull request.

Misconceptions include believing that CD always means continuous deployment, that a single pipeline must own everything from commit to production, and that CI/CD is only a matter of tools. DORA's change lead time, measured from commit to running in production, spans both halves and shows how well they work together.

At associate level, expect questions that place an activity on the correct side of the hand-off, distinguish delivery from deployment, or compare push-based and pull-based ways of connecting a pipeline to a cluster.