Breaking Down the Continuous Delivery Ecosystem
Achieving Continuous Delivery allows us to enable the DevOps lifecycle where we can continuously deliver value while empowering teams, reducing errors, and lowering stress.
Continuous Delivery (CD) is about how, where, when, and what we deliver. CD applies to any organization that owns software services and it can be used to accelerate their processes and achieve the benefits of DevOps.
DevOps is the ability to continuously deliver value by working with people, processes, and technology. At the intersection of these components are the benefits of DevOps:
● Reliable infrastructure managed as code
● Frequent and reduced time to market
● Improved software quality and performance
● Improved organizational productivity
● Faster problem resolution and solving
DevOps is not just a one and done deal but more of a mindset incorporating ways of working that include automation, cross-functional agile teams, and cloud solutions.
The Continuous Delivery Playbook
CD involves more than Continuous Integration (CI). When working with CI, a development team is primarily concerned with the generation of a deployable artifact. Source code changes managed by a version control system will trigger the building and testing of an artifact often from source code. When working with CD cross-functional delivery teams consider how to provision infrastructure, how to manage change approvals, how to release and rollback, how to verify, how to manage CI/CD pipelines and security, and how to gain insights into delivery metrics.
Through CD, we can also avoid software delivery antipatterns which add to engineering toil and slow down organizations looking to achieve the benefits of DevOps. Some antipatterns include deploying software manually, long release cycles, and manual environment management.
By combining areas of engineering and IT expertise, we overcome the challenges of software delivery. However, this task of combining areas of expertise involves working with different people, processes and solutions. To achieve enterprise trusted Continuous Delivery we need to navigate the CD ecosystem. So let’s share a playbook that incorporates the major components of Continuous Delivery.
Every application runs on some hardware. Infrastructure provisioning is about creating target environments for our deployments and delivery. The purpose of creating best practices around infrastructure provisioning is to limit direct and manual changes.
To enable Continuous Delivery, you should have a plan for how to provision infrastructure, for example using infrastructure as code. Include in your playbook how you would like to deploy and configure the specific environment and infrastructure and manage future upgrades and maintenance of your servers.
Organizations have a process to ensure software changes comply with existing standards and requirements. Change management refers to these processes. In change management processes, organizations incorporate a change management board or a process for managing the approval of deployments to specific environments.
The requirements for assurance grows as artifacts are promoted into higher environments.
Change management process serves as a barrier for deployments, and may even be a manual process. Consider how your Continuous Delivery process incorporates the sign off of deployments. Important characteristics regarding the deployment need to be easily accessible and tracked, such as what is being deployed, who is deploying the service, and where the service is being deployed.
You can’t improve what you can’t measure. Continuous Delivery requires verification that systems are working properly and as expected. Verification tools offer feedback to all software delivery stakeholders and organizations should look to ensure that feedback is a shared responsibility.
When developing a verification process for deployments consider how tools are instrumented through systems and application code. There are two kinds of instrumentation: explicit and implicit instrumentation will indicate the work necessary to implement a verification or observability solution. Second, determine a plan for data storage. Where will log files be stored for later analysis? How long will these files be stored? Third, consider data aggregation. Metrics are meant to be aggregated over time. Consider a plan for how to visualize and present data collected. And finally, determine altering and event notifications. Under what circumstances and conditions should someone receive an alert? Who should receive said notification?
Release Strategies and Rollback
Reduce the risk of a deployment by defining a release and rollback strategy. There are two ways to release a deployment, either release a service to replace the existing service or release while keeping an old version of the service running. Some release strategies include a rolling, blue-green, or canary deployment.
The same way you release a deployment is the same way you should rollback. If you keep an old version of an application running and a deployment fails, the rollback strategy should be to remove the failed version. Similarly, if you replaced existing services to do a deployment, you’ll need a strategy for redeploying your service to a known stable version.
A core principle of Continuous Delivery is the Continuous Delivery pipeline. Pipelines allow delivery teams to release repeatedly, and reliability to a target environment. Other principles include automation, self-service, and continuous improvement. Pipelines are the main features that can include all other delivery practices mentioned, such as infrastructure provisioning, change management, verification, and releasing.
All pipelines should be idempotent, meaning running a deployment pipeline should not affect running the same pipeline in the future. Any failures of the pipeline should not affect future iterations of work.
Discuss who should have access to certain pipelines and consider push-button functionality for deployments via pipelines.
Audit and Compliance
Security is integral to every organization and can not be an afterthought. Continuous Delivery processes should always consider who, what, when, where, and why. Consider how to capture this information regarding deployments with your Continuous Delivery solution.
Likewise, DevSecOps and the secrets management solutions and processes that have emerged within the decade have helped standardize security for organizations, which is why security and secret management shouldn’t be difficult for engineers who are deploying. Consider secret management best practices and determine how your Continuous Delivery process handles sensitive information.
The effects of Fast Delivery
Achieving Continuous Delivery allows us to enable the DevOps lifecycle where we can continuously deliver value while empowering teams, reducing errors, and lowering stress. This blog post shares a playbook for Continuous Delivery. Check out our Continuous Delivery as-a-Service platform and sign up for a demo or free trial.
This post summarizes the “Continuous Delivery Playbook” session from the DevOps Institute's Continuous Delivery Ecosystem SKILup Day this past month. You can watch the recording here: https://devopsinstitute.com/continuous-delivery-ecosystem-skilup-day/