What Is a CI/CD Pipeline? Stages, Tools and a First Setup

A CI/CD pipeline is an automated sequence that takes every code change from the moment it is committed to the moment it runs in production, checking it at each step. CI, continuous integration, means everyone merges small changes into the main branch often, and each one is built and tested automatically. CD means either continuous delivery, where every change that passes is ready to release and a person decides when, or continuous deployment, where every change that passes goes live on its own. The usual stages are source, build, test, package, deploy and verify. A good first pipeline builds and tests every pull request in a few minutes, and on each merge to main builds once, deploys to staging, deploys the same build to production, and checks that it is healthy.

What CI/CD means

• Continuous integration. GitHub’s documentation↗ (opens in a new tab) defines it as “a software practice that requires frequently committing code to a shared repository,” with each commit built and tested so errors surface while they are small. Linters, security checks, code coverage and functional tests all belong here.
• Continuous delivery. DORA’s guide to continuous delivery↗ (opens in a new tab) calls it “the ability to release changes of all kinds on demand quickly, safely, and sustainably.” The software is always in a deployable state, and releasing is a decision rather than a project.
• Continuous deployment. Every change that passes the pipeline goes to production automatically, with no person pressing a button. DORA notes it suits web services but cannot be applied to firmware or mobile apps, and that you can and should start with continuous delivery even if you never move to continuous deployment.

Vendors do not always draw that line. GitHub’s own continuous deployment page describes CD as “the practice of using automation to publish and deploy software updates” and does not separate delivery from deployment, while DORA says the two are “commonly conflated” but separate practices. When someone on your team says “CD,” ask which one they mean: the difference is whether a person approves each production release.

Why teams bother

Integration gets harder the longer work stays apart: a month of separate changes is far harder to merge than a day’s. DORA’s page on continuous integration↗ (opens in a new tab) cites research showing teams perform better when developers merge into trunk at least daily, and sets two requirements: every commit triggers a build, and every commit triggers automated tests that give feedback in a few minutes. It adds a team agreement that matters as much as the tooling: when the build breaks, fixing it comes before any other work.

The stages of a CI/CD pipeline

1. Source. Something triggers the pipeline: a push, a pull request, a merge to main, a schedule or a manual run. How branches reach main is its own decision; git branching strategy compares the options.
2. Build. Install dependencies exactly as the lockfile says and compile or bundle the code. Builds should be repeatable: the same commit produces the same result on any runner.
3. Test. Fast checks first, lint and unit tests, then integration tests and security scans such as dependency audits and secret scanning. Keep the pull request checks under about ten minutes and run slower suites after the merge.
4. Package. Produce one versioned artifact, such as a container image, a zip file or an app bundle, tagged with the commit it came from, and store it where later stages can fetch it.
5. Deploy. Put that same artifact into staging, then production. Configuration and secrets come from the environment, never from the code, and production can wait for a person’s approval.
6. Verify. Smoke-test the key paths, watch health checks and error rates, and roll back automatically if they fail. Separating deploy from release with feature flags makes this stage far less tense.

Every tool names these parts differently, but the shape is the same. GitLab’s CI/CD documentation↗ (opens in a new tab) describes a pipeline as stages and jobs: stages set the order, typically build, test and deploy, jobs are the tasks inside each stage, and runners are the agents that execute them. GitHub Actions calls the same ideas workflows, jobs, steps and runners.

A vendor-neutral starter pipeline

This is the smallest pipeline worth having, written as plain steps you can translate into any tool’s configuration file.

ON EVERY PULL REQUEST                              goal: under 10 minutes
  1. check out the code
  2. install dependencies from the lockfile
  3. lint
  4. run unit tests
  5. build (proves it compiles; the result is thrown away)
  -> result shown on the pull request; merging requires all green

ON EVERY MERGE TO MAIN
  1. check out, install, lint, test again (on the merged code)
  2. build ONCE -> artifact tagged with the commit SHA
  3. deploy the artifact to staging
  4. smoke test staging: home page, sign-in, one key user flow
  5. wait for approval               <- continuous delivery
     (or skip this step)             <- continuous deployment
  6. deploy the SAME artifact to production
  7. verify: health check and error rate for 15 minutes
     -> if either fails, roll back to the previous artifact

• Keep main green. A red main branch blocks everyone, so fixing it is the first job of whoever broke it.
• Build once, promote the same artifact. Rebuilding for production means production runs something staging never tested.
• Keep the pipeline file in the repository and review changes to it like code.
• Keep secrets in the CI tool’s secret store, scoped to the environment that needs them, never in the file or the logs.
• Fix flaky tests or quarantine them the day they appear. A test that fails at random teaches everyone to ignore red.

On GitHub, GitHub Actions for CI/CD turns this into a working YAML file, with caching, secrets and an environment that waits for approval.

Choosing a CI/CD tool

Most teams start with the CI/CD built into their code host: GitHub Actions for code on GitHub, GitLab CI/CD for GitLab, Azure Pipelines for Azure DevOps and Bitbucket Pipelines for Bitbucket. Self-hosted servers such as Jenkins suit teams that must run everything on their own machines. Compare them on a few questions rather than feature lists:

• Where does the code live, and does the tool report results on its pull or merge requests?
• Hosted runners, self-hosted runners, or both? Self-hosted is more control and more upkeep.
• How are secrets stored and scoped, and can a production deploy require a named approver?
• Is the whole pipeline defined in a file in the repository?
• How is usage counted: by minutes, by concurrent jobs or by seats? Check each vendor’s own pages for current terms.

What to measure

DORA’s software delivery performance metrics↗ (opens in a new tab) are a common yardstick. DORA now uses five, where it once used four, and groups them into throughput and instability:

• Change lead time: how long a change takes from being committed to version control to running in production.
• Deployment frequency: how many deployments happen in a period, or the time between them.
• Failed deployment recovery time: how long it takes to recover from a deployment that fails and needs immediate intervention.
• Change fail rate: the share of deployments that need immediate intervention afterward, such as a rollback or a hotfix.
• Deployment rework rate: the share of deployments that were unplanned and happened because of an incident in production.

DORA lists three of those under throughput, including recovery time, and the last two under instability, and its research finds that speed and stability are not trade-offs: top performers do well on all five. It also warns against turning the numbers into targets, comparing unlike applications, and relying on one metric. Alongside them, watch your pipeline’s own health: how long a pull request waits for checks, how often main is red, and how many failures turn out to be flaky tests.

Tracking the work the pipeline ships

A green pipeline says a change passed its checks; it does not say whether the feature someone asked for is finished or whether anyone checked it in production. That belongs on the task. On a fenbs board, put the task’s ref, such as BUG-042, in the pull request title; after the deploy, set the task’s test status to Tested, Partly tested, Failed or Needs owner check, write in the test notes what was checked and where, and move it to Completed. The board’s “Completed, not tested” filter is the question to ask before the next release. fenbs does not connect to your CI tool, so a person or a connected AI assistant makes those updates, and History records which one did. The finished tasks then become the raw material for your release notes.