This article is based on reporting originally published by SD Times, drawing on Amalgam Insights’ “The 2020 Guide to Continuous Integration and Continuous Delivery” and commentary from industry practitioners.
CI/CD Pipelines Are Growing Up
CI/CD pipelines are no longer just a mechanism to get code from a developer’s laptop into production. As organizations push for higher release velocity and broader automation coverage, the definition of what a CI/CD pipeline should look like — and what it should include — is actively expanding.
Research analyst firm Amalgam Insights addressed this evolution in its report “The 2020 Guide to Continuous Integration and Continuous Delivery: Process, Projects and Products,” authored by Tom Petrocelli. The report provides a structured framework for understanding both basic and extended pipeline models, and draws a clear line between CI/CD as a process discipline and DevOps as an organizational strategy.
The Basic CI/CD Pipeline: Five Core Stages
According to the Amalgam Insights report, a basic CI/CD pipeline consists of five sequential processes:
- Merge – Combining developer code branches into a shared codebase.
- Build – Compiling source code and its dependencies into a deployable artifact.
- Test – Running automated tests to validate the build.
- Package – Bundling the tested artifact for distribution, often moving it into a repository.
- Deploy – Releasing the packaged artifact to a target environment.
Each stage can contain sub-pipelines. For example, moving a build artifact into an artifact repository is a sub-step within the package stage. While the flow appears linear, loopbacks occur in practice — a failed test or a flagged security scan will route work back to an earlier stage.
The Extended CI/CD Pipeline: Ten Stages for Full Lifecycle Automation
An extended pipeline doubles the number of explicit stages to ten, adding planning, security, artifact management, and monitoring around the basic core:
- Plan
- Code
- Merge
- Build
- Test
- Security Scan
- Package
- Artifact Repository
- Deploy
- Monitor
“The standard pipeline is just the basic stuff. Once my code has been written, how do I get it to release?” said Petrocelli. “When you think about an extended tool chain — which is where a lot of the vendors are going — you start to bring in other things like monitoring.”
By connecting more of the software development lifecycle into the pipeline, teams gain end-to-end visibility and more opportunities for automation. Manual steps may still exist — for example, a human sign-off before production deployment — but they become explicit handoffs rather than invisible gaps.
Why the Full Lifecycle Matters
Hasan Yasar, technical manager of the Secure Lifecycle Solutions group in the CERT Division of the Software Engineering Institute at Carnegie Mellon University, frames this similarly:
“The point of a pipeline is basically to help build an application, test the application, deliver the application, and deploy it into production. A pipeline is not just having continuous integration servers or deployment tools and techniques, but covering the full life cycle.”
Hasan Yasar, Carnegie Mellon University SEI
By “full life cycle,” Yasar means coverage from inception through build, test, delivery, deployment, and ongoing production monitoring.
What a Full-Lifecycle Pipeline Needs
Yasar’s recommended tooling components for a mature pipeline include:
- An issue tracking system to manage work items and requirements
- A build system for compiling and packaging code
- An integration environment for validating assembled components
- A communications system (such as a team chat tool) to support collaboration
- Monitoring systems capable of tracking the health of multiple development environments
- A central repository management system connected to all other components, storing all artifacts including infrastructure-as-code
The central repository is critical: it ensures that all stakeholders — not only developers — can access build artifacts, infrastructure definitions, and test results. Everything should be integrated; isolated tools that don’t communicate create the same visibility gaps the pipeline is meant to eliminate.
End-to-End Solutions vs. Point Solutions
The market has responded to extended pipeline demands in two ways: point solutions that do one thing well, and end-to-end platforms that cover the full chain. The Amalgam Insights report identifies vendors moving toward end-to-end solutions, including Atlassian, AWS CodePipeline, CircleCI, CloudBees, GitHub, GitLab, Google, Oracle, Pivotal (now part of VMware), and Red Hat.
The case for end-to-end platforms is straightforward: components are designed to work together, reducing integration overhead. Petrocelli makes the velocity argument directly:
“Complexity works against you when you want to achieve higher velocity. Without these tools, it’s going to be hard to have a microservices architecture. You’re not going to get what you want to get out of it, which is faster and more frequent updates.”
Tom Petrocelli, Amalgam Insights
However, end-to-end platforms are not always the right answer. The classic trade-off applies: breadth versus depth. Organizations with complex requirements, heterogeneous environments, or no commitment to a single cloud provider may find best-of-breed point solutions preferable. Petrocelli also notes that cloud providers and platform vendors often bundle CI/CD toolchains at no extra cost — a strategy that encourages vendor lock-in.
Whatever approach an organization takes, tooling decisions should account for the full application portfolio, including legacy applications alongside cloud-native services. Creating a two-tier organization where some teams benefit from automation and others do not generates internal friction and uneven delivery performance.
DevOps and CI/CD Are Not the Same Thing
One of the more practically useful distinctions in the Amalgam Insights report is the separation of DevOps from CI/CD — two terms that are frequently conflated.
DevOps: Organizational Strategy
DevOps, as defined in the report, is a project and organizational strategy. It is conceptual and has no fixed implementation. Teams that adopt DevOps restructure how people, processes, and incentives are aligned — not which tools they use.
“A lot of teams call themselves ‘DevOps’ when they’re really doing a tool chain. Many of them aren’t running integrated DevOps teams. If you’re not doing the management piece, you’re not doing DevOps.”
Tom Petrocelli, Amalgam Insights
CI/CD: Process Automation
CI/CD, by contrast, is process automation — specifically, the process of taking raw developer code and other build artifacts and turning them into running applications and services. You can implement a robust CI/CD pipeline without practicing DevOps, and you can practice DevOps without a CI/CD toolchain.
Continuous Delivery vs. Continuous Deployment
Even within CI/CD, the terminology is inconsistent in practice. The report draws a specific distinction between two commonly confused terms:
| Term | Definition | Deployment Step |
|---|---|---|
| Continuous Delivery | Code is always in a releasable state; releases are triggered manually | Manual |
| Continuous Deployment | Every change that passes automated tests is deployed to production automatically | Automated |
Continuous deployment is what high-frequency digital-native organizations practice when shipping hundreds or thousands of releases per day. Continuous delivery is the more practical model for most organizations, where a human decision gate remains before production release. The two terms are not interchangeable, though they are regularly used as if they were.
Microservices as the Forcing Function
Much of the pressure to extend and formalize CI/CD pipelines originates from microservices adoption. When an application is composed of dozens or hundreds of independently deployable services, manual release management becomes untenable. Automation is not optional — it is the only way to achieve the deployment frequency that microservices architectures are designed to enable.
Conversely, organizations running monolithic applications that change infrequently may have less immediate pressure to invest in extended pipeline automation. The architecture of the application, not any particular industry trend, should drive the pipeline investment decision.
Key Takeaways
- A basic CI/CD pipeline covers merge, build, test, package, and deploy. An extended pipeline adds planning, coding, security scanning, artifact repository management, and monitoring.
- Pipelines are never truly linear — failures and security findings create loopbacks to earlier stages.
- A central artifact repository, connected to all other tooling, is the architectural hub of a mature pipeline.
- End-to-end platforms reduce integration complexity; point solutions offer deeper functionality for specific needs. Cloud-provider toolchains are often bundled to encourage lock-in.
- DevOps is an organizational strategy; CI/CD is process automation. They are complementary but independent.
- Continuous delivery retains a manual deployment gate; continuous deployment removes it entirely.
- Microservices adoption is the primary driver of demand for extended, highly automated CI/CD pipelines.