- What Is Continuous Delivery?
- Implementing Continuous Delivery
- Managing Projects with Continuous Delivery
- How Can I Tell If I'm Really Doing Continuous Delivery?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Implementing Continuous Delivery
Continuous delivery depends on both technical and organizational foundations in order to succeed. There are three pillars to these foundations: comprehensive configuration management, an agile approach to testing, and the deployment pipeline.
Configuration Management
In terms of configuration management, there are four elements that are essential to continuous delivery:
- First, it should be possible to build, test and deploy your application in a fully automated fashion. That means that source code, test scripts, build and deployment scripts, and database migration scripts all need to be kept in version control.
- Second, the deploy-time and runtime configuration of your applications needs to be managed in a consistent, centralized fashion.
- Third, it should be possible to create or apply a configuration change to every one of your environments using a fully automated process.
- Finally, all development must be done on mainline, with larger features and restructuring implemented incrementally so that the application is always kept working. Incomplete features can be made unavailable through the UI using configuration settings, if required.
Effective configuration and release management also depends on great co-operation between developers and operations staff (including DBAs) throughout the delivery process. Operations teams need to be present on delivery teams from the beginning of each project in order to ensure their requirements are fed in to the analysis process, and that the application is deployed to production-like environments for functional and cross-functional testing from early on in the development process. This kind of collaboration is one of the key cultural changes proposed by the DevOps movement.
Agile Testing
The second pillar that continuous delivery rests on is an agile approach to testing. Again, this has both technical and organizational components. From an engineering point of view, it’s necessary to automate tests at every level: unit, component, and acceptance (functional and non-functional). You need to be sure that if your automated test suites pass, your software is releasable. That means that it contains no regressions, and satisfies the requirements of the business—including capacity and availability—in a production environment.
Agile testing relies on quality being built into the delivery process. That means that testing isn’t a phase—it’s something that happens throughout the delivery lifecycle. Similarly, the quality of the system is the responsibility of the whole delivery team, not just the testers or QAs. Testers and analysts need to work together to create acceptance criteria that are testable. Testers and developers should collaborate on creating automated acceptance tests that verify the acceptance criteria are met as part of the development process, a technique known as acceptance test-driven development. Developers need to take responsibility for maintaining acceptance tests, and ensuring they are kept green.
The Deployment Pipeline
The third pillar of continuous delivery is the deployment pipeline. The deployment pipeline is essentially a living model of your delivery process—the part of your value stream from check-in to release. You can model it using a tool like Go. Every change to your system’s configuration goes through the deployment pipeline, which creates a build of your system, runs your automated tests against it, and then makes it available for deployment to testing and production environments. You can think of the deployment pipeline as an extension of continuous integration that takes it beyond the development team into the testing and operations team.
The tool you use to model and control your deployment pipeline becomes a system of record for builds, recording which version they came from in version control, who deployed them to which environments when, and what the results were. The deployment pipeline should enforce your delivery workflow, including authentication and authorization, and thus can be used to audit your entire delivery process. Because the pipeline models your development and deployment process, it is a rich source of data for discovering where the bottlenecks are, and working to continuously improve your delivery process.