What is CI/CD?
CI/CD stands for continuous integration and continuous delivery/deployment — the automated building, testing and shipping of software. Code changes are continuously merged, checked automatically and brought into test and production environments in a controlled way through a pipeline.
Also known as: continuous integration · continuous delivery · continuous deployment · build pipeline
Where CI/CD is used
Continuous integration (CI) means that developers merge their changes into a shared state frequently, with automated builds and tests immediately checking that everything fits together. Continuous delivery (CD) ensures that every checked version could be shipped at any time; with continuous deployment, the release even happens fully automatically.
Technically this is represented through a pipeline — a defined sequence of steps such as build, test, security check and deployment. In the Microsoft world, Azure DevOps Pipelines or GitHub Actions are used for this.
A practical example
For a SaaS platform, every code change is built and tested automatically. If it passes all checks, it is shipped through the pipeline first to a test environment and, after approval, in a controlled way to production. This makes releases traceable, repeatable and free of manual error sources — even with a short time to market.
How it relates & how smiit uses it
CI/CD is a concrete building block of the overarching DevOps way of working and is often combined with infrastructure as code so that not only the code but also the environment is rolled out reproducibly. For Claimity AG, smiit built DevOps pipelines that enabled automated delivery and contributed significantly to taking the platform live on Azure in just six weeks.
Common mistakes & misconceptions
- CI and CD are often lumped together; continuous integration means frequently merging and automatically testing code, while continuous delivery or deployment concerns releasing it.
- Many believe having a pipeline already means continuous integration; without meaningful automated tests it is just an automated build with no real quality assurance.
- People assume continuous deployment fits every team; without mature tests, monitoring and rollback strategies, automatically shipping to production is risky.
Frequently asked questions
What is the difference between continuous delivery and continuous deployment?
With continuous delivery, every checked version can be shipped at any time, but the final step into production happens on approval. With continuous deployment, this step is fully automated too.
Is CI/CD worthwhile for small teams too?
Yes. Even a simple pipeline for automated building and testing significantly reduces errors and manual effort. CI/CD can be introduced step by step and grow over time.
What typically belongs in a CI/CD pipeline?
A pipeline consists of consecutive steps, usually build, automated tests, security checks and deployment to the respective environment. The exact shape depends on the project, but the principle stays the same: every step is automated and traceable.
What happens when a build or test fails in the pipeline?
If a step fails, the pipeline stops and the change is not shipped any further. This prevents faulty states from reaching test or production environments in the first place, and the team gets clear, early feedback on the cause.
How do CI/CD and infrastructure as code relate?
CI/CD automates building and shipping the software, infrastructure as code describes the associated environment. When both are combined, application and infrastructure can be rolled out reproducibly together instead of maintaining the environment manually.
Related terms
Sources & further reading
Want to put this topic to work in your company?
Updated · Back to the glossary