CI/CD
/siː aɪ siː diː/ · Abbreviation · Development · Origin: 2000
Definitions
CI/CD stands for Continuous Integration and Continuous Deployment (or Continuous Delivery). Continuous Integration is the practice of automatically building and testing code every time a developer pushes changes to a shared repository, catching bugs and integration conflicts early. Continuous Delivery extends this by ensuring that code is always in a deployable state, while Continuous Deployment goes further by automatically releasing every passing build to production. Together, these practices reduce the time between writing code and getting it in front of users, from weeks or months down to minutes. Popular CI/CD platforms include Jenkins, GitHub Actions, GitLab CI, CircleCI, and Travis CI. A typical pipeline includes stages for linting, unit tests, integration tests, security scans, artifact builds, and deployment. CI/CD is a cornerstone of DevOps culture, enabling teams to ship smaller changes more frequently, roll back quickly when issues arise, and maintain confidence in the quality of their releases.
In plain English: An automated system that tests your code every time you save changes and can automatically publish it if everything passes — no manual steps needed.
Continuous Delivery (CD) means every commit is deployable but requires manual approval to release. Continuous Deployment means every commit that passes tests automatically goes to production. The difference is a human gate — and whether your tests are good enough to trust.
Example: 'We practice continuous delivery, not continuous deployment. Every commit could ship, but product decides when to actually push the button.'
Source: delivery vs. deployment distinction
Etymology
- 1991
- Grady Booch introduces the term 'continuous integration' in his Object-Oriented Analysis and Design.
- 2000
- Extreme Programming (XP) popularizes continuous integration as a core practice. CruiseControl launches.
- 2006
- Jez Humble and David Farley begin formalizing continuous delivery practices, later published in their 2010 book.
- 2011
- Jenkins (forked from Hudson) becomes the dominant open-source CI server, making CI/CD accessible to all teams.
- 2019
- GitHub Actions launches, embedding CI/CD directly into the code hosting platform. GitOps gains momentum.
Origin Story
The Pipeline That Never Sleeps
CI/CD, standing for Continuous Integration and Continuous Delivery (or Deployment), represents two practices that transformed how software is built and shipped. Continuous Integration traces back to Grady Booch, who first described the concept in his 1991 book on object-oriented design. But the practice truly took shape in the late 1990s as part of Extreme Programming (XP), championed by Kent Beck. The core idea: developers should merge their code changes into a shared repository frequently, ideally multiple times a day, with automated builds and tests verifying each merge. Martin Fowler and Matthew Foemmel codified the practice in a 2000 article that became the CI bible. Continuous Delivery extended the concept further, proposing that software should always be in a deployable state. Jez Humble and David Farley's 2010 book 'Continuous Delivery' laid out the full pipeline from code commit to production release. The cultural shift was enormous. Before CI/CD, software releases were rare, painful events involving weeks of manual testing. With CI/CD, teams could ship updates hourly. Tools like Jenkins (2011), Travis CI (2011), CircleCI (2012), and GitHub Actions (2019) made these pipelines accessible to teams of all sizes.
Context: Extreme Programming / Agile movement, late 1990s-2000s
Fun fact: Amazon deploys code to production on average every 11.7 seconds, a feat made possible by CI/CD pipelines that run thousands of automated tests before each deployment.