CI/CD: definition, pipeline stages and how to set it up

CI/CD (continuous integration, continuous delivery and continuous deployment) is the set of practices that runs every code change through an automated chain of building, testing and release. This guide gives the definition, separates its three parts, describes the stages of a pipeline and its security, and explains how to set it up on an application that already exists.

It is written for technical leaders, CIOs and product managers who want to release more often without breaking production, and who wonder where to start. CI/CD is at the heart of our infrastructure, DevOps and web security offer.

What is CI/CD?

CI/CD means automating the path from a code change to its release in production. “CI” stands for continuous integration; “CD” stands, depending on the context, for continuous delivery or continuous deployment. The three follow one another: each builds on the previous one.

Martin Fowler, who popularised the term, defines continuous integration as a practice where each member of a team merges their changes into the shared codebase, together with their colleagues’ changes, at least daily. Jez Humble, co-author of the book Continuous Delivery, defines continuous delivery as the ability to get changes of all types into production safely, quickly and sustainably.

The CI/CD pipeline is the automated chain that applies these practices: for every change, it builds, tests, analyses, packages and deploys, and stops as soon as a stage fails. CI/CD is one of the core practices of DevOps, the approach that brings together the people who build an application and those who run it.

Continuous integration, delivery, deployment: what is the difference?

The difference lies in where automation stops. Continuous integration stops at merged and tested code; continuous delivery, at a version ready to ship; continuous deployment goes all the way to production, without human approval.

GitLab sums it up in its CI/CD overview: with continuous delivery, the software can be released at any time and deployment is triggered manually; continuous deployment deploys automatically, without human intervention. Most business applications stop at continuous delivery: a person chooses when to release, often to fit in with users.

What are the stages of a CI/CD pipeline?

A CI/CD pipeline usually chains eight stages, each of which can stop the chain. The details vary from one application to another; the order changes little.

• The trigger. A change is pushed to the code repository or a merge request is opened.
• The build. The code is assembled with its dependencies, always the same way, with no manual step.
• Automated tests. Unit tests first, which are fast; then integration tests. A failing test stops the chain.
• Code and dependency analysis. Code quality, known vulnerabilities in the libraries used, secrets left in the code.
• The package (artefact). A container image or an archive, built once, identified by its version, which stays the same from staging to production.
• Deployment to staging. The package is installed on an environment as close as possible to production, with test data.
• Validation. End-to-end tests, performance or accessibility checks, then functional acceptance by the client when planned.
• Release and monitoring. The same package goes to production; logs and alerts show whether all is well, and rolling back to the previous version remains possible.

Two rules hold it all together. The pipeline must stay fast: Martin Fowler considers the guideline of a ten-minute build reasonable for most projects. And a broken pipeline is fixed straight away, before any new feature, otherwise nobody trusts it any more.

Staging data deserve the same attention as the code: copying the production database to a test environment raises data protection issues. Our article on test data and the GDPR details the options. The tests themselves are part of our quality assurance and testing offer.

Which tool should you choose for a CI/CD pipeline?

The right CI/CD tool is first of all the one that lives next to your code. GitHub Actions if the code is on GitHub, GitLab CI if it is on GitLab; Jenkins when everything must be hosted in-house and fully customised; CircleCI or other hosted services when you want to delegate execution.

Four questions separate the tools better than a feature comparison:

• Where is the code? A tool built into the repository avoids managing one more access.
• Where do the jobs run? On the vendor’s machines, or on yours when the code or the data must not leave.
• How are secrets kept? Passwords and production access keys must be stored separately, encrypted, and available only to the stages that need them.
• Who will be able to maintain it? A pipeline written in readable files, versioned with the code, can be taken over; a configuration clicked together in an interface gets lost.

The iones team sets up pipelines on GitHub Actions, GitLab CI, Jenkins or CircleCI, depending on what the client already uses. The choice of tool matters less than the discipline: tests that run on every change, and a pipeline that is fixed as soon as it breaks.

How do you secure a CI/CD pipeline?

A CI/CD pipeline must be secured like a production system, because it holds the keys: it reads the code, holds secrets and writes to production. An attack on the pipeline is an attack on the application.

The OWASP Foundation has published a list of the ten main security risks specific to CI/CD (Top 10 CI/CD Security Risks). They include insufficient control over what can reach production, overly broad identity and access management, dependency chain abuse, poisoned pipeline execution, poor credential hygiene, and missing artefact integrity validation. In the United States, NIST devoted a whole publication in February 2024 to software supply chain security in CI/CD pipelines (SP 800-204D).

• Nobody pushes to production alone. A change to the main branch goes through review and through the pipeline, without exception.
• Least privilege. Each pipeline stage only has access to what it needs; service accounts are separate from personal accounts.
• Secrets outside the code. Stored in a vault or in the tool’s secrets manager, rotated regularly, never printed in logs.
• Monitored dependencies. Pinned versions, scanning for known vulnerabilities on every build, tracked updates.
• Verifiable packages. What goes to production is indeed what the pipeline built and tested.
• Retained logs. Who ran what, when, with which result.

For a software publisher, these measures also prepare for the obligations of the Cyber Resilience Act: knowing what each version contains and quickly fixing a flaw in a dependency.

How do you set up CI/CD on an existing application?

On an existing application, CI/CD is set up step by step, starting with what protects most: an automated build and a few tests, before any automated deployment.

• Take stock. Where the code is, how a release happens today, who does it, how many manual steps, which tests exist. An audit of the existing application answers these questions.
• Put all the code under version control. The code, but also the configuration and the deployment scripts. What is not versioned cannot be automated.
• Automate the build. A single command, run on every change, that produces the application without intervention.
• Add tests on critical functions. An application without tests will not have hundreds of them in a week: start with the user journeys the business depends on.
• Automate deployment to staging. Then the release to production, triggered by hand at first (continuous delivery).
• Monitor and know how to roll back. Alerts on production and a tested procedure to return to the previous version.

An old application, without tests or documentation, makes this path longer: each step reveals part of its technical debt. This is often the case when taking over a web application, where the pipeline becomes the new team’s first safety net.

How do you measure what CI/CD changes?

What CI/CD changes is measured with a few delivery metrics, taken before and after it is set up. The DORA research programme, now run by Google Cloud, lists five of them in its guide updated on 5 January 2026:

The first three show whether you deliver fast, the last two whether you deliver well. Tracking them together avoids gaining speed at the cost of stability. For an application under maintenance, the change fail rate joins the indicators of corrective maintenance: fewer failed deployments mean fewer defects to fix in a hurry.

Frequently asked questions

CI/CD: start with a self-testing build

CI/CD does not start with a tool, but with a habit: integrate often, build and test on every change, fix whatever breaks straight away. Automated deployment comes next, once the tests deserve the trust placed in them.

The iones team designs and sets up CI/CD pipelines, from the initial assessment to production, as part of its infrastructure, DevOps and web security offer. To review your delivery chain, write to us.