CI/CD stands for Continuous Integration and Continuous Delivery (or Continuous Deployment). It’s a set of automated practices that help development teams ship software changes frequently and reliably.
Continuous Integration (CI): Every time a developer pushes code changes, automated processes build the code and run tests. If something breaks, the team knows immediately.
Continuous Delivery (CD): After CI passes, the changes are automatically prepared for release. A human still approves the final deployment to production.
Continuous Deployment: Takes CD one step further — every change that passes automated tests is automatically deployed to production with no manual approval.
You’ll hear this when…
CI/CD comes up in engineering team discussions, hiring conversations, and tool evaluations. “What’s your CI/CD pipeline?” means “how do you automatically build, test, and ship code?” Common CI/CD tools include GitHub Actions, GitLab CI, Jenkins, and CircleCI.
A “broken build” or “red pipeline” means the CI process detected a problem — tests failed, the code won’t compile, or a dependency is missing. Teams that practise CI/CD aim to keep the pipeline green (all checks passing) at all times.
Why it matters
Before CI/CD, deploying software was often a manual, error-prone event that happened weekly or monthly. CI/CD enables teams to deploy multiple times per day with confidence, because every change is automatically verified before it reaches users.
For how “pipeline” means different things across industries — including the development pipeline — see why every industry reinvents the word “pipeline”.