Every software owner is in the business of delivering their services quickly, repeatedly, and reliably. So, what does this process involve, and why are there challenges? Read on for more information as this blog post shares everything you need to know about Continuous Delivery (CD).
Continuous Delivery is a term that came about in 2010, following conversations around Continuous Integration. In 2006, Martin Fowler advocated the practice of continuously integrating developer code into codebases in an automated, efficient, and well-tested manner to reduce errors and accelerate software development. By 2008, the growth of Hudson CI, which would later be replaced by Jenkins in 2011, popularized this practice.
A book titled Continuous Delivery by Jez Humble and David Farley extended techniques to the entire software development life cycle, specifically discussing putting code into production environments. In this book, Jez Humble and David Farley define Continuous Delivery as “the practice of ensuring that software is always ready to be deployed.” In other words, CD is the automated process of taking an artifact throughout the various steps necessary for the software changes to be made available to a consumer. These changes live in a production environment ready to be released in the future. Let’s explain this practice in more detail.
Continuous Delivery Explained
The goal of continuous delivery is to deliver a packaged artifact into a production environment. CD automates the entire delivery process, including the deployment process. CD responsibilities can include provisioning infrastructure, managing changes (ticketing), deploying artifacts, verifying and monitoring those changes, and ensuring these changes do not happen if there are any issues.
Continuous Delivery vs. Continuous Integration
Continuous Integration (CI) is an automated process for continually integrating software development changes. CI processes automate the building, testing, and validation of source code. By working with CI capabilities, development teams accelerate their code release cycles, making it less likely to run into long feature development cycles and the challenges that come with it, such as merge conflicts and broken code.
Therefore, CI is about integrating new features and code changes into an artifact. In a typical development workflow, a developer:
- Write codes
- Checks in code using a version control system / configuration management tool
- This new codebase goes through a build process
- The build is packaged into an artifact
- And then, the artifact is stored within a repository.
The goal of CI is to produce a packaged artifact that is ready to deploy onto a server or machine. An example of an artifact can be a container image, WAR/JAR file, or any other executable packaged code. Therefore, CI activities are a requirement for CD.
CI/CD is a shortened term for Continuous Integration and Continuous Delivery. CI/CD is a DevOps practice that involves the combination of principles, practices, and capabilities that allow for software changes of all kinds to get to users in a quick, repeatable, and safe manner. This allows for software developers to integrate their feature or service changes continuously, and for IT and operations teams to deliver with the standards, security, and confidence businesses need in their release process.
Continuous Delivery vs. Continuous Deployment
Continuous Deployment is the automation of Continuous Delivery. In Continuous Deployment, software changes are released to customers on demand. Unlike continuous deployment, in continuous delivery, organizations control when production deployments happen.
This can seem very dangerous as new code changes become live as soon as the deployment pipeline is complete. However, this is where deployment strategies and progressive delivery can be helpful. These techniques allow teams to test in production and observe or test changes before they impact the entire user base.
Fundamentals of Continuous Delivery
Now that we know more about continuous delivery, let’s discuss the fundamental components of CD, starting with some useful terminology.
A service is a running instance of an application. Services vary in purpose and architecture, ranging from microservices, self-contained applications that run alongside other services to larger monolithic applications. Common examples of services include Kubernetes containers, Databases, and Node.js applications.
An artifact is a package of everything a software service needs to run on a machine. This includes the codebase and any packages or requirements needed. An artifact is a service that gets built, packaged, and prepared for deployment.
An example of an artifact is a container image. Kubernetes workloads require you to specify information about your codebase alongside specific details of your runtime. Once a container image is built, this packaged code, alongside its dependencies, is ready for deployment. Some teams at this point may run container scanning solutions, and version control their artifacts to prepare for a release.
Components of Continuous Delivery
As shown, the continuous delivery process requires an artifact, and it involves infrastructure, change management, deployment, verification, and rollback/failure strategies.
There are generally six components to a Continuous Delivery pipeline, given an artifact that is ready for deployment.
- Accessing cloud, on-prem, or hybrid environments
- Provisioning infrastructure
- Change management and approvals
- Employing a deployment strategy
- Verifying performance
- And defining a failure or rollback strategy.
A CD pipeline automates these activities.
A stage in a Continuous Delivery pipeline represents a phase of activities. These stages modularize the pipeline, giving organizations the flexibility to templatize different pipelines for their services. Some services may not need additional workaround change management or verification, while others do. Stages call out a group of activities, like deploy to a development environment or test in the quality assurance (QA) environment.
Workflows consist of the activities belonging to a stage. Workflows typically automate three things: deploying the service, testing and verifying the service, and then rollback (if necessary).
For example, if stage 1 of our CD pipeline is deploying to a non-production environment, then our workflow may include activities such as:
- Provisioning a QA environment in AWS
- Deploying my artifact to a QA environment
- Running a bunch of tests
- Tearing down the environment
- Approving a Jira ticket (or alternatively, filing a ticket for bug fix).
Notice that each workflow allows an artifact or a number of artifacts to progress through the CD process and its defined stages.
An environment is the target infrastructure for deployment. This can be:
- A Kubernetes cluster or namespace
- A public cloud instance such as AWS, Azure, Google Cloud, etc
- Or a private data center.
Stages are involved with environments, and so CD pipelines are defined by their target environments.
A pipeline combines stages, workflows, and environments.
A trigger is an event that starts the pipeline process. This trigger can be manual or automated in CI, CD, or CI/CD pipeline. Here are some examples of triggers:
- Merging your Git branch into master
- A new artifact is available in your artifact repository
- A new .tar artifact file has been uploaded to a folder for deployment
- A recurring time
- And, a webhook.
Benefits of Continuous Delivery
Continuous Delivery not only makes for faster time to market, but it also allows teams to release software on a regular basis. This cadence and repeatability produces a feedback loop which allows developers and ops teams to collaborate and deliver continuous value in short cycles.
Overcoming Challenges in Continuous Delivery
That said, there are a number of challenges in Continuous Delivery. Some of these challenges include testing, managing scripts, and ensuring security.
Balancing quality with delivery is not easy. Many new features or code changes can go untested when a team is short on time or resources. Continuous Delivery depends on testing and verifying capabilities. Automated tests can be helpful in measuring and understanding performance, especially when they are run in production-like environments.
Script files are a set of commands. While scripts are useful for automating quickly, they often don’t scale or simplify for Continuous Delivery pipelines. Scripting your pipeline can lead to configuration issues, tribal knowledge that can’t be shared for other teams, and brittle pipelines that break and are resistant to change.
Security is everyone’s responsibility. Building CI/CD pipeline implementations that ensure a level of security can be a challenge when the CD solution does not support key management solutions out of the box. Governance and compliance is one step towards ensuring service security in a CI/CD pipeline.
Build CI/CD Pipelines in Minutes with Harness
This blog post shares the fundamentals of Continuous Delivery and how it relates to other activities and practices in the software delivery life cycle. Building, testing, deploying, and verifying your services on-demand is easy with Harness, an all-in-one software delivery platform. Try it for yourself today.