Continuous Delivery (CD) is clearly a hot topic right now. Businesses know that getting new features out to their users faster is essential. However, finding information on how to start implementing CD in a real-world situation is something organizations still find challenging.
CD is a set of patterns and best practices that can help software teams dramatically improve the pace and quality of their software delivery. The core idea is to create a repeatable, reliable pipeline for taking software from concept to customer. Continuous Delivery enables an organization to continuously make small changes to a system with automated tests to validate the code that is promoted and released.
The benefits of CD are easy to grasp: faster time-to-market, higher quality applications, and improved customer responsiveness.
How to Battle the Complex Environment of CD in the Real Word
Building a CD pipeline isn't too difficult when there’s just one application in a greenfield setup. That pristine situation, however, is atypical to the one most enterprises face: trying to do CD with a vast array of different applications, components and services, connected by a complex web of interdependencies.
In my experience, enterprises are always likely to find themselves in situations where they need to support a diverse set of teams with different CD goals and different levels of CD maturity.
Given the complexity of the app landscape, I think the main goal of organizations should be to look for tools that allows them to support what their teams are currently doing while helping them to transition to the desired “goal state.” Such tools will enable organizations to embrace Continuous Delivery at their own pace - and are far preferable to tools that they can only use once.
Tools should support real-world application delivery scenarios for deployment, release/pipeline orchestration, and testing. Tools should support not just the 'Latest and Greatest' technologies and trends, but also the technologies and trends that have been in place for years.
At the same time, enterprises need to find tools to help them transition to the latest and greatest delivery models appropriate to their businesses, and adopt industry-standard practices without enforcing a 'one size must fit all' approach.
What Does This Mean In Practice? Some Examples
Ideally, tools should allow you to choose the unit of deployment that makes most sense, and even aggregate multiple deployments into one 'batch' as changes move toward production. So, for example, a deployment package should include one or more changes and be transitioned all the way from Development to Production. However, the tools you choose should support delivery models such as “fan-in,” whereby multiple components are individually tested and only “bundled” into a unit for the last stages on the way to Production.
Other Examples
Alternatively, you could start with two deployment packages, each containing one change that could be deployed to Development and Test and then combine them into an aggregate solution containing both changes for deployments to Quality Assurance and Production.
Here are other options: you could trigger a release pipeline for each change, or set up a triggering strategy that waits for a certain time or until X changes have been accumulated before starting a pipeline. A hybrid 'fan-in' approach is common. The first section of the delivery pipeline runs per change to perform basic validation, and the section of the pipeline that leads to production runs only when sufficient changes have been accumulated, similar to the common 'release train' concept.
This approach fits well with microservice release landscapes, where each component service may have its own 'first section' of the overall pipeline that verifies each service in isolation, before a second section picks up a batch of services and performs dependency validation and integration testing all the way up to production.
Summary
Continuous Delivery can provide tremendous value to organizations in any industry. However, each organization should make its own decisions about how much of CD it wants to adopt based on its unique business needs. Finally, it is worth noting that CD is more of a means to an end rather than an end in itself. Tools can only help you achieve your goals if you are following a well-defined plan.