EXPLAINER

CI and CD

Continuous integration automatically builds and tests every change. Continuous delivery prepares a deployable artifact; continuous deployment ships it. The point is a repeatable pipeline, not a YAML file that nobody trusts.

Short answer: CI builds and tests each change. CD delivers or deploys the artifact that passed. Start with one pipeline that runs tests on a pull request. Do not deploy from a laptop once more than one person can break production.

What it is

Continuous integration (CI) means every change is merged into a shared branch often and is built and tested automatically when it is proposed. Continuous delivery means the result of that pipeline is an artifact you can release at any time, with a human usually pressing the button. Continuous deployment means a green pipeline deploys itself. People say CI/CD for the whole idea and then argue about the second C. The useful distinction is: tests on every change, and a deploy path that is not "SSH in and pull".

The pipeline is code, often YAML in GitHub Actions, GitLab CI, or a cloud build service. It is not a person running npm test and then deploying from a laptop, even if that person is reliable.

Why and when it is used

Use CI as soon as two people, or one person on two days, can forget a step. A red build should mean "this change fails tests", not "the agent is out of disk". Use CD when production deploys have ever depended on someone's local Node version or a forgotten migration.

You do not need a complex pipeline for a static page. You do need one before you have a database migration and a secret and a second environment. Start smaller than the diagrams. One job that installs dependencies, runs tests, and fails the pull request is a real CI system.

How it works

A trigger (pull request, push to main, a tag) starts a clean runner. The runner checks out the commit, installs toolchains, and runs commands you listed. Caches speed installs and can also poison you if they never invalidate. Artifacts (a test report, a container image, a zip) are stored. A later job or a manual approval deploys that artifact. The deploy should use the image or package the tests already built, not rebuild from a different commit.

Secrets are injected as environment variables or files and must not be printed. Branch protections stop a merge when the check is red. Environments (staging, production) can require different approvals. A migration runs as a step you can identify, not as a side effect of app startup that two instances attempt at once.

Technologies and dependencies

A Git host, a CI service, and scripts that work non-interactively. Containers are a common artifact. Git is how the change arrives. Environment Variables and the CI system's secret store configure deploy steps. Flaky tests are a dependency you must not ignore; a pipeline people rerun until it is green is not a signal.

How to get started

  1. Pick the one command that means "tests passed" on a laptop. Make it non-interactive.
  2. Add a workflow that runs it on pull requests using a clean checkout.
  3. Require that check before merge.
  4. Make the workflow build an artifact. Save it. Do not deploy yet.
  5. Add a staging deploy of that same artifact, triggered manually.
  6. When staging is boring, automate production with the approval you actually want.

Pin third-party actions and tool versions. A pipeline that installs "latest" will break on a Tuesday you did not choose.

Cautions and trade-offs

A green pipeline that skips tests is theatre. A pipeline that deploys a different commit than it tested is how "CI passed" and production is wrong. Long pipelines that take forty minutes train people to bypass them.

Secrets in logs, overly broad cloud credentials on the runner, and pull requests from forks that can read secrets are the security failures. Least privilege applies to CI identities. And do not confuse frequent deploys with careless ones. The point of CD is that deploy is small and reversible, which requires migrations that expand safely and a way to roll back the artifact. If you cannot roll back, you do not have continuous delivery. You have continuous hope.