The course is part of this learning path
DevOps Adoption Playbook - Part 2 - Intro
DevOps Adoption Playbook - Part 2
DevOps Adoption Playbook - Part 2 - Demonstration
DevOps Adoption Playbook - Part 2 - Review
In this course we introduce you to the DevOps Playbook Part 2.
The DevOps Playbook Part 2 course continues with Books 8 through to 12, covering the topics, Infrastructure as Code, Configuration Management, Continuous Delivery, Continuous Deployment, and Continuous Monitoring, where each book documents a required DevOps competency, one in which you’ll need to adopt and establish skills in to be effective in DevOps.
- Book 8 - Infrastructure as Code
- Book 9 - Configuration Management
- Book 10 - Continuous Delivery
- Book 11 - Continuous Deployment
- Book 12 - Continuous Monitoring
The DevOps Playbook Part 2 course includes 2 demonstrations where we put into practice some of the DevOps theory presented.
- Atlassian BitBucket Pipelines and Terraform
- Atlassian BitBucket Pipelines Promoting Staging to Production
Note: the source code as used within these demonstrations is available at:
- [Instructor] Welcome back, in this lecture we'll introduce you to Continuous Delivery and how it support deployment releases into production.
Continuous Delivery is the practice of delivering updates into production and to end users in a manner that is fast, safe and sustainable. Updates being pushed into production can include new features, configuration changes, bug fixes and/or experiments. Continuous delivery is dependent upon three previous DevOps practices we have already covered, that is comprehensive configuration management, continuous integration, and continuous testing. The key goal of Continuous Delivery is to be able to deploy all types of change, in a predictable and routine manner such that if required, they can also be performed on demand at any time, and very quickly. This is achieved by ensuring that the codebase is always in a deployable state. In essence we are industrializing the process of moving any and all change captured within our version control system all the way through into production.
Continuous Delivery automates all parts of the process, however the final deployment of a release into production may involve a manual approval process. With everything in place a deployment into production can happen multiple times daily or even hourly. Continuous Delivery is achieved through the use of deployment pipelines. Deployment pipelines pull together continuous integration, configuration management, and test and deployment automation processes. In doing so a deployment pipeline provides a unified process which not only improves overall software quality, but improves time to market, reduces overall effort and cost, and strengthens the stability of the product as experienced by the end user. The general pattern and sequence for a deployment pipeline consists of the following. One, a version control system triggering a Continuous Integration cycle when changes are committed. Two, the Continuous Integration cycle performs a build and runs all automated test suites. Three, if all tests are passed, the Continuous Integration cycle builds a release package. Four, manual approval may be requested to finally perform the deployment and configuration into production.
The benefits of employing a Continuous Delivery practice include the following. Time to Market. It's quicker for each update or a lease. Lease times can be in the order of minutes. Software quality. Using automated testing tools to discover integration defects and regressions early on, prevents them from getting into production, increasing the overall quality. Product Development Focus. Developers can maintain focus on core product enhancements and not have to waste time on performing tests on their code. Low-risk Deployment Events. Software deployments become pain free, low-risk events that can be performed at any time, and on demand. Reduced effort and costs. Over the course of time, the effort and cost associated with individual deployments will be considerably less due to the levels of automation and minimal manual effort required.
Known challenges associated with using Continuous Delivery to automate the build and deployment workflow are, Inadequate Tests. Weak test quality and under test coverage result and deployments that contain issues once released into production. Organizational Issues. Releases into production often require cooperation between different teams. Different teams have different agendas and perceived territories of control which may impact the ability to perform continuous delivery. Manual Impedance. Production releases often require change advisory board approval and/or respective paperwork. Excessive red tape will be detrimental to the success of continuous delivery. Deployment Unit Size. Works well with small units of change. Old school architectures, such as monolithic may impact the effectiveness of continuous delivery.
Some example continuous delivery tools that are available in the market are, Octopus Deploy. An automated release management tool for modern developers and DevOps teams, mainly targeted at Windows hosts. Shippable, a Software as a Service automation platform for Continuous Integration and Continuous Delivery that takes care of all the heavy lifting. Codar, a continuous deployment solution that provides automation and release management of complex multi-tier applications across the application lifecycle. XL Deploy, an application release automation solution that is agentless across all target platforms. GoCD, an open source tool which is used in software development to help teams and organizations automate the continuous delivery of software.
In the example shown here, developers check in their updates into Github which in turn triggers a build on the latest version of the source code. The build server performs all test suites and if everything passes requests manual approval before pushing the release into production.
Ensure that you have adequate and appropriate tests configured within your pipeline to guarantee the deployment package will give the desired results as experienced by the end user. The final manual approval message should be delivered to the appropriate member or group within the DevOps team, who has the necessary authority to release into production, and can do so in a timely manner.
Okay, that completes this lecture on Continuous Delivery. Go ahead and close this lecture, and we'll see you shortly in the next one.
About the Author
Jeremy is the DevOps Content Lead at Cloud Academy where he specializes in developing technical training documentation for DevOps.
He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 20+ years. In recent times, Jeremy has been focused on DevOps, Cloud, Security, and Machine Learning.
Jeremy holds professional certifications for both the AWS and GCP cloud platforms.