What is a CI/CD pipeline? Stages and tools explained

Continuous integration: merge small, verify automatically

Continuous integration is the practice of merging code changes into a shared repository frequently — typically many times a day across a team — with every merge automatically triggering a build and a run of the test suite. The alternative it replaced was long-lived separate branches merged rarely, which produced the dreaded “integration phase”: weeks of work colliding at once, with conflicts and breakages discovered long after the code was written.

The automation is what makes the practice stick. A CI server watches the repository; every push is built and tested without anyone remembering to do it, and a failure is reported within minutes, while the change is still small and fresh in its author’s mind. The effect is a codebase that is verified continuously rather than occasionally — which is the foundation everything downstream depends on: you cannot safely automate deployment of code you have not automatically tested.

Continuous delivery vs continuous deployment — the distinction matters

The two CDs are often conflated, but they name genuinely different practices. Continuous delivery means every change that passes the pipeline is automatically prepared for release — built, tested, packaged — so the software is always in a releasable state; the final push to production remains a deliberate human decision, often a single button. Continuous deployment removes that last gate: every change that passes all automated checks goes to production automatically, with no human in the loop.

Continuous delivery is the sensible default for most teams, and for regulated or high-stakes environments the manual gate is a feature, not a weakness. Continuous deployment demands exceptional confidence in the automated tests — they are now the only thing standing between a bad change and production — plus mature monitoring and fast rollback. Which one a team practises says a great deal about its testing maturity, and exam questions on this topic frequently hinge on knowing exactly where the human approval sits in each.

The stages of a typical pipeline

Pipelines vary in detail, but almost all follow the same backbone, with each stage acting as a quality gate — a change only advances by passing the stage before:

1. Source — a developer pushes a commit (or merges a pull request) to the repository, which triggers the pipeline automatically.
2. Build — the code is compiled or packaged into a deployable artefact, such as a container image, with dependencies resolved; a change that cannot build stops here.
3. Test — automated checks run against the built artefact: unit tests first, then typically integration tests, and often security and code-quality scans; failures halt the pipeline and notify the author.
4. Deploy — the verified artefact is released to an environment, usually staging first and then production, either after a manual approval (continuous delivery) or automatically (continuous deployment).

Why pipelines reduce risk

It can seem paradoxical that deploying more often makes releases safer, but the logic is straightforward. Small, frequent changes are individually easy to review, easy to test and — crucially — easy to diagnose: when something breaks minutes after a ten-line deployment, the culprit is obvious in a way it never is after a six-month release of hundreds of changes. Fast feedback compounds this: the pipeline reports failures while the author still has full context, instead of during a distant release week.

Automation removes the other great source of release failure: humans performing long manual checklists under pressure. The pipeline performs the same steps identically every time, and because deployment is a repeatable, versioned process, rolling back becomes routine — redeploy the previous artefact — rather than an emergency improvisation. Mature pipelines go further with gradual rollout strategies, sending a new version to a small slice of traffic first and promoting it only when monitoring stays healthy. The net effect inverts the old assumption: release frequency and release safety rise together.

The tool landscape, including the cloud-native options

Every pipeline needs an engine, and the market offers many: long-standing self-hosted servers such as Jenkins, and hosted services built into the code platforms — GitHub Actions being the one you are most likely to meet first, since it runs workflows directly from configuration files kept in the repository alongside the code. GitLab CI/CD follows the same model on its platform. Defining the pipeline in a versioned file in the repository is now the norm across tools: the pipeline itself gets the same review and history as the code it ships.

The clouds offer native suites, worth knowing by name for certification study. On AWS: AWS CodePipeline orchestrates the overall workflow, AWS CodeBuild compiles and tests, and AWS CodeDeploy automates deployments to compute services — with the deep AWS integration you would expect. On Azure, Azure DevOps is the umbrella suite whose pipeline engine is Azure Pipelines, which can build and deploy to Azure and beyond; GitHub Actions (GitHub being a Microsoft product) is equally at home deploying to Azure. None of these is universally best — teams generally pick the engine adjacent to where their code already lives.

Where CI/CD appears in certification study

CI/CD sits squarely in the developer and operations wings of the certification tracks. The AWS Developer Associate (DVA-C02) exam covers it most directly: the CodePipeline, CodeBuild and CodeDeploy family, deployment strategies, and how automated pipelines interact with the services applications run on. The AWS CloudOps Engineer Associate (SOA-C03) approaches it from the operations side — reliable, repeatable deployment and rollback as day-to-day practice. On the Azure track, AZ-104 administrators are expected to understand the deployment tooling around the platform they run. Exam scenarios often hinge on precisely the distinctions in this article — which stage failed, where the approval gate belongs, which deployment strategy limits blast radius. If the pipeline stages feel like second nature, those questions become descriptions of a machine you already understand; our revision lessons take each named service to exam depth.