Back to Glossary
DeliveryC

CI/CD (Continuous Integration / Continuous Delivery)

Definition

CI/CD stands for Continuous Integration and Continuous Delivery (or Continuous Deployment). It is a set of practices and tools that automate the process of building, testing, and releasing software. The "CI" part means developers integrate their code changes into a shared repository frequently (ideally multiple times per day), and each integration triggers an automated build and test suite. The "CD" part means the resulting artifact is always ready for release.

In practice, CI/CD is implemented through a pipeline -- a sequence of automated steps that code passes through on its way to production. A typical pipeline: developer pushes code, automated tests run (unit, integration, end-to-end), the code is built into a deployable artifact, and it is staged for release. Tools like GitHub Actions, GitLab CI, Jenkins, and CircleCI orchestrate these pipelines.

The DORA (DevOps Research and Assessment) metrics program at Google found that elite-performing teams deploy on demand (multiple times per day), with a lead time from commit to deploy of less than one hour. Low-performing teams deploy between once per month and once every six months. CI/CD is the infrastructure that separates these two realities.

Why It Matters for Product Managers

CI/CD shapes your release strategy. Without it, you are stuck with infrequent, risky releases where dozens of changes ship together and any bug could be caused by any of them. With CI/CD, you can ship individual changes, feature flag them for gradual rollout, and roll back in minutes if something goes wrong.

This has direct product implications. If deploying is cheap and fast, you can run more experiments, validate ideas with real users sooner, and fix issues before they escalate. If deploying is expensive and slow, every release becomes a high-stakes event that discourages experimentation and rewards playing it safe.

PMs do not configure CI/CD pipelines themselves, but they need to understand the team's deployment capability when planning releases. Asking "how long from code complete to production?" and "what is the rollback process?" are basic questions that inform realistic timelines.

How It Works in Practice

  • Code commit -- A developer pushes their changes to a branch and opens a pull request. This triggers the CI pipeline automatically.
  • Automated testing -- The pipeline runs the full test suite: unit tests (seconds), integration tests (minutes), and sometimes end-to-end tests (minutes to tens of minutes). If any test fails, the pipeline stops and the developer is notified.
  • Build -- If tests pass, the pipeline builds the application artifact (a Docker container, a compiled binary, or a deployable bundle). This ensures the code compiles and packages correctly.
  • Staging deployment -- The artifact is deployed to a staging environment that mirrors production. PMs and QA can verify the change in staging before approving production release.
  • Production deployment -- With CD, deploying to production is a single action (click a button or merge to main). With Continuous Deployment, this step is automatic -- no human approval needed. Teams at Netflix, Amazon, and Etsy deploy thousands of times per day using this model.
  • Monitoring and rollback -- After deployment, automated monitoring watches for error rate spikes. If anomalies are detected, the pipeline can automatically roll back to the previous version.
  • Common Pitfalls

  • Slow pipelines that nobody waits for. If the CI pipeline takes 45 minutes, developers will merge without waiting for results, defeating the purpose. Target under 10 minutes for the full CI cycle.
  • Flaky tests that cry wolf. Tests that pass and fail randomly erode trust in the pipeline. Teams start ignoring failures, and real bugs slip through. Fix or delete flaky tests immediately.
  • No staging environment. Going directly from CI to production without a staging step means PMs and QA cannot verify changes before users see them. This is fine for high-maturity teams with strong automated tests; risky for everyone else.
  • Treating CI/CD as purely an engineering concern. PMs who do not understand the deployment pipeline make unrealistic commitments about release timing and cannot effectively plan incremental rollouts.
  • Continuous Delivery -- the "CD" half of CI/CD, focused on keeping software always releasable
  • DevOps -- the broader cultural practice that CI/CD enables
  • Feature Flag -- the technique that pairs with CI/CD to decouple deployment from release
  • Frequently Asked Questions

    What is the difference between Continuous Integration and Continuous Delivery?+
    Continuous Integration (CI) means developers merge code into a shared branch frequently (multiple times per day), and each merge triggers automated builds and tests. Continuous Delivery (CD) extends this by ensuring the code is always in a deployable state and can be released to production with a single click. Continuous Deployment goes one step further -- every change that passes tests is automatically deployed without human approval.
    Why should a PM care about CI/CD?+
    CI/CD directly affects how fast your team can ship. Teams without CI/CD typically release every 2-4 weeks with painful manual deploy processes. Teams with mature CI/CD can deploy multiple times per day. That means faster experimentation, quicker bug fixes, and the ability to release features incrementally behind feature flags instead of big-bang launches.

    Explore More PM Terms

    Browse our complete glossary of 100+ product management terms.