What is CI/CD? | Harness Glossary | Harness

CI/CD is a software development practice that automates the path from a code commit to a running application in production. It combines Continuous Integration (CI), which builds and tests every code change automatically, with Continuous Delivery or Continuous Deployment (CD), which moves that validated code through testing environments and into production.

The two halves solve two different problems. CI includes the build process, where code is packaged into software. CD marches that software through test environments and into production. Along the CI/CD path, tests and security scans are run to determine whether that production release should happen. If not, the system should deliver clear feedback to developers and their agents.

CI/CD unpins most modern DevOps practices. It's also one of the most commonly searched terms in software delivery, and for good reason: almost every team eventually has to decide how much of their release process to automate, and CI/CD is the framework for that decision.

Why does CI/CD matter?

Before CI/CD became standard practice, teams merged code in large batches, tested it late, and deployed it manually. That approach worked when releases happened once a quarter. It breaks down completely once teams try to ship weekly, daily, or faster.

CI/CD matters for three reasons.

It catches problems while they're cheap to fix. A bug found seconds after a commit takes minutes to diagnose. The same bug found three weeks later, buried under someone else's changes, can take days.

It removes the manual toil from releases. Build steps, test runs, and deployment sequences that used to require a person clicking through a checklist now run the same way every time, without someone staying late to babysit a release.

It closes the gap between writing code and shipping it. This has become more urgent in recent years. Harness's 2026 State of DevOps Modernization Report found that 22% of deployments cause enough trouble to require a rollback, a hotfix, or an incident, and that 79% of teams making heavy use of AI coding assistants describe their pipelines as plagued by flakiness. AI has made it cheap to write code. It hasn't made it any faster to deliver that code safely, and CI/CD is the layer that has to close that gap.

DORA's research backs this up at a broader level: delivery speed and stability aren't opposites. Teams with strong automation and fast feedback loops tend to ship more often and see fewer failures, not a tradeoff between the two.

What's the difference between CI, Continuous Delivery, and Continuous Deployment?

This is where most confusion starts, mostly because "CD" gets used for two different things. Continuous Delivery and Continuous Deployment are both abbreviated CD, and they're related but not identical.

‍

Continuous Delivery and Continuous Deployment aren't a maturity ranking where one is strictly better. They're a choice about risk tolerance. A bank processing regulated transactions might keep a manual approval gate for compliance reasons even with excellent test coverage. A SaaS product with strong automated testing might deploy every merged change without anyone touching a button. Both can be run well.

For a deeper look at how Continuous Integration works day to day, see What Is Continuous Integration (CI)?. For the delivery side, see What Is Continuous Delivery (CD)?.

How does a CI/CD pipeline work?

A CI/CD pipeline runs through four phases. Every platform names them slightly differently, but the sequence is consistent.

Source

A developer commits code to a shared repository, usually Git. This triggers the pipeline. Everything downstream depends on this commit being small enough to review and test quickly, so teams that commit often tend to have healthier pipelines than teams that batch up large changes.

Build

The pipeline compiles the code, resolves dependencies, and produces a deployable artifact, such as a container image or a packaged binary. If the build fails, the pipeline stops here and notifies the developer immediately.

Test

Automated tests run against the build: unit tests first, then integration, security, and performance tests as needed. This is where the pipeline does most of its work. A failing test blocks the change from moving forward.

Deploy

The validated artifact moves into a test or staging environment, and from there to production. This is where Continuous Delivery and Continuous Deployment diverge: Delivery stops at a manual approval before production, and Deployment doesn't.

For a walkthrough of what each stage looks like in practice, including where teams typically add friction without meaning to, see Harness's guide to the CI/CD pipeline.

How does CI/CD relate to DevOps?

DevOps is the broader cultural and organizational practice of breaking down the wall between development and operations teams. CI/CD is how DevOps gets implemented in the pipeline itself.

You can think of it this way: DevOps sets the goal of shipping value to customers faster and more reliably, with development and operations sharing responsibility for the outcome. CI/CD provides the automated mechanism that makes that goal achievable at any real scale. Without CI/CD, "DevOps" is mostly a meeting where dev and ops agree to communicate better. With CI/CD, it's a working system that actually moves code.

Platform engineering has become the natural extension of both. As pipelines multiply across dozens or hundreds of services, platform teams build the golden paths, templates, and guardrails that keep every team's CI/CD pipeline consistent without forcing every developer to become a pipeline expert.

What are the benefits of CI/CD?

Faster release cycles. Teams that automate build, test, and deployment can ship in minutes instead of days. Citi, for example, cut its build-to-production time to under seven minutes after automating a process that used to take hours to days of manual promotion between environments.

Fewer failed deployments. Automated testing and gated releases catch problems before they reach customers, which lowers change failure rate and shortens the time it takes to recover when something does go wrong.

Lower operational cost. Automating what used to require manual pipeline maintenance frees up engineering time. Deluxe reported a 72% reduction in CI/CD costs after consolidating fragmented tooling into a standardized pipeline.

What are common CI/CD challenges?

Slow, flaky pipelines. Long queue times and intermittent test failures teach developers to ignore CI results, which defeats the purpose of having them. The fix is usually to automate the selection of tests to run, parallelize test execution, cache dependencies, and treat flaky tests as bugs to fix rather than noise to tolerate.

Late-stage security scanning. Scanning for vulnerabilities only right before a release means problems get caught late, when they're expensive to fix. Moving dependency scanning and secret detection into the CI stage catches issues while the context is still fresh.

Tool sprawl across the pipeline. Separate tools for build, artifact storage, deployment, and database changes each need their own configuration, credentials, and maintenance. That overhead compounds as an organization adds more services and more pipelines.

What tools do teams use for CI/CD?

CI/CD tooling generally falls into three categories: dedicated CI tools, dedicated CD tools, and integrated CI/CD solutions. 

CI-focused tools handle building and testing code, including Jenkins, GitHub Actions, and Harness. CD-focused tools are more oriented toward deploying code and governing whether a deployment should happen. Tools include Argo CD, Octopus Deploy, and Harness.

Platform-level tools combine both, along with governance, artifact management, and database change automation, so a team isn't stitching together five separate products by hand. GitLab, Azure DevOps, and Harness Software Delivery Agent are examples of integrated CI/CD platforms. 

Which category to start with depends on what's currently broken. A team with reliable builds but painful, manual deployments needs a CD tool first. A team still fighting merge conflicts and slow test feedback should fix CI before worrying about deployment automation at all. A team wasting effort integrating too many tools or using a legacy CI tool for everything should go for a platform approach.

What are CI/CD best practices?

Commit small and often. Small, frequent changes are easier to review, easier to test, and far easier to roll back if something goes wrong. Long-lived feature branches tend to produce the opposite of all three.

Deliver things the same way. There’s a temptation to roll out different toolchains for each stack. Code to Kubernetes is done one way, database schema updates another, and infrastructure updates a third. Add in agents, virtual machines, and COTS apps, and it gets out of control quickly. Standardize on a pipeline framework and use it as widely as possible.

Automate testing at every stage. Fast unit tests belong on every commit. Slower integration and security tests can run on merge or on a schedule. The goal is fast feedback for the common case and thorough coverage before release.

Make the pipeline the only path to production. Every manual exception to the pipeline, even a well-intentioned one for an urgent fix, erodes the confidence that the pipeline reflects what's actually running. If exceptions keep happening, that's a signal the pipeline is too slow or too rigid, not a reason to keep bypassing it.

Automate policy. The less you have to rely on people to enforce your rules, the better. Hard policy gates in the pipeline are your friend. Increasingly, teams leverage Policy as Code to standardize and automate policy.

Verify deployments: Deployment to production is often the culmination of the CI/CD pipeline, but it’s also the riskiest moment. Tapping in to your observability stack from your pipeline so that you can automatically understand if something has been broken and trigger a rollback is a key safety lever.

Where is CI/CD headed next?

Two forces are reshaping what a modern CI/CD pipeline needs to do.

The first is AI-generated code arriving faster than pipelines can absorb it. Coding assistants have made it cheap to produce changes, but review, test, and deployment haven't sped up to match. That's the gap behind the flakiness and rollback numbers cited earlier, and it's pushing teams to treat pipeline speed and reliability as a first-class engineering problem rather than an afterthought.

The second is governance moving earlier in the pipeline rather than being bolted on at the end. Policy checks, security scans, and audit evidence increasingly get generated as changes move through CI/CD, rather than assembled after the fact for a compliance review. As release cadence increases, that automatic evidence trail becomes the only realistic way to stay auditable without slowing everyone down.

The end result is that CI/CD is moving towards being a component of an autonomous SDLC. The risk and manual toil involved in delivering a new line of code to production need to be driven down towards zero. That means ruthless automation throughout the pipeline is required to run all the safety checks, make a release decision, land it in production, and verify that it’s working.

Frequently asked questions About CI/CD

What does CI/CD stand for?

CI/CD stands for Continuous Integration and Continuous Delivery, or sometimes Continuous Integration and Continuous Deployment. The "CI" half is consistent. The "CD" half depends on whether a team keeps a manual approval step before production (Delivery) or ships automatically (Deployment).

What is the difference between CI and CD?

CI automates building and testing every code change as it's merged. CD automates what happens after that: packaging the change, deploying it to test environments, and either preparing it for a manual release (Continuous Delivery) or deploying it straight to production (Continuous Deployment).

Is CI/CD the same thing as DevOps?

No. DevOps is the broader practice of aligning development and operations around shared ownership of software delivery. CI/CD is the automated pipeline that makes DevOps practical to run at scale, but DevOps also includes culture, incident response, and organizational structure that go beyond any single pipeline.

Do I need Continuous Deployment, or is Continuous Delivery enough?

Most teams don't need to remove the final manual approval to get real value from CI/CD. Continuous Delivery already gets you a release-ready build on demand. Continuous Deployment makes sense once test coverage and rollback automation are strong enough that a human approval isn't catching anything a machine couldn't catch faster.

What is a CI/CD pipeline?

A CI/CD pipeline is the automated sequence that carries a code change from commit through build, test, and deployment. It's the concrete implementation of CI/CD practices, usually defined as configuration or code so it runs the same way every time.

Can small teams benefit from CI/CD?

Yes. The core benefit, catching problems early and removing manual release steps, matters at any team size. Small teams often see the payoff faster, since they can adopt a straightforward pipeline without the coordination overhead that larger organizations face.

CI/CD is the layer where most of the real work in modern software delivery happens: build, deployments, artifacts, and increasingly, the database and infrastructure changes that ship alongside application code. If you're evaluating how to bring these pieces together, Harness's Builds and Code Deployments capabilities extend CI/CD automation across that full path, from commit to production. Start with the fundamentals in Continuous Integration and Continuous Delivery, then see how the pieces connect in the CI/CD pipeline guide.