CI/CD basics went viral

A lot of teams still ship code like moving day: everyone carries boxes at once, something breaks, and nobody knows which box caused it. Continuous integration was invented to stop that by having developers merge small changes into one shared codebase and run automated builds and tests every time. (docs.aws.amazon.com) A build is the step where raw source files get turned into something runnable, like compiling an app or packaging a service. GitHub’s documentation describes continuous integration as workflows that build code and run tests automatically after changes land in a repository. (docs.github.com) That first half is the “continuous integration” in the name. Amazon defines it as developers regularly merging code into a central repository, followed by automated builds and tests, so bugs show up when the change is still small. (aws.amazon.com) The second half is where teams decide what happens after the tests pass. Amazon’s guidance says “continuous delivery” means software is automatically tested and prepared for release, but a human still approves the final move into production. (docs.aws.amazon.com) “Continuous deployment” removes that last manual gate. GitHub’s deployment docs and Amazon’s pipeline guide both describe it as code going live automatically once preconfigured checks succeed. (docs.github.com) (aws.amazon.com) That is why the letters confuse people: the “C” always means continuous, but the “D” can mean delivery or deployment depending on where the approval step sits. GitHub’s 2024 CI/CD guide explicitly notes that CI/CD is commonly expanded as continuous integration plus either continuous deployment or continuous delivery. (github.com) The word “pipeline” is just the assembly line that connects those steps in order. GitLab documents pipelines as the core building blocks of CI/CD, with jobs and stages defined in a YAML file so the same sequence runs the same way every time. (docs.gitlab.com) In practice, one pipeline might run a formatter, then unit tests, then package an image, then deploy to a staging server, then wait for approval before production. GitHub Actions calls itself a continuous integration and continuous delivery platform and shows workflows that test on every push or deploy merged pull requests to production. (docs.github.com) That plain-language breakdown is why a short explainer could travel so far this week. It turns a term that often sounds like tool jargon into one simple split: continuous integration catches problems when code is merged, and continuous delivery or deployment decides how that tested code reaches users. (aws.amazon.com) (docs.gitlab.com) For teams rebuilding release processes in 2026, that distinction is not trivia. GitLab’s docs say CI/CD reduces the chance of building on buggy previous versions, and Amazon’s guidance says the same automation lowers deployment risk and speeds delivery, which is exactly why companies standardize these pipelines before they try to ship faster. (docs.gitlab.com) (docs.aws.amazon.com)