This post is from the XebiaLabs blog and has not been updated since the original publish date.
Continuous Delivery in the Real World: How to move from "thinking in Releases" to CD?
A comment we frequently hear from users is that one of the key things they value about working with XebiaLabs is that we don't just provide useful tools, we actually help them get to grips with the challenges of trying to introduce Continuous Delivery in a real world scenario. Building a pipeline doesn't sound all that difficult when you're talking about one application with one pipeline in a greenfield setup. But that's not at all the situation most enterprises find themselves in: how do you move towards CD if your starting point is a diverse set of projects with pretty different release processes where you do not have one app making its way to Production, but tens or hundreds of applications, components or services with complex interdependencies? We regularly have interesting and insightful discussions with users on these kind of topics, and I would like to share some of the points raised, as they apply to many of the organizations we speak to. "Continuous Delivery requires a substantial investment in creating and maintaining metadata about process and artifacts (deploy scripts, config files, etc.). It also requires a high level of discipline about processes. ARA, as with much of the rest of the CD approach, is oriented toward modern technologies and cloud infrastructure. That does not describe all of our applications, even in target-state. This would have us applying ARA techniques to older technologies and dev processes. This situation occurs frequently for us:
- Two changes must be made to an application.
- Deployers prefer to implement the changes separately to reduce risk in their processes (aligned to CD principles)
- App owners (both business and IT) prefer to implement the changes together to reduce testing effort and expense."
Our experience is also that enterprises will always have a mix of approaches to many process related to Devops and application delivery, both across teams or groups and over time within individual teams. Our aim is very clearly to support real-world application delivery scenarios, so it essential for us that all our tools – whether for deployment, release/pipeline orchestration or testing – support not just the "Latest and Greatest" new technologies and trends, but also the practices that are in place today within organizations. What we regard as critical is that our architecture allows you to support this spectrum effectively and investigate new approaches and technologies easily. Our tools aim to help you transition to new delivery models where appropriate to your business context and adopt industry-standard practices without enforcing a "one size must fit all" approach. Applied to this particular example: our deployment tools should allow you to choose the unit of deployment that makes most sense, and even aggregate multiple deployments into one "batch" as the change set moves toward production. So a deployment package might include one or both changes and be transitioned all the way from Dev to Prod. Or we could start with two deployment packages, each containing one change, could be deployed to e.g. Dev and Test and then be combined into an aggregate containing both changes for deployments to QA and Production. Similarly, we could decide to trigger a release pipeline for each change, or set up a triggering strategy that waits for a certain time or until N 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 also fits well with SOA/microservices release landscapes, where each component service may have its own "first section" of the overall pipeline that verifies that service in isolation, before a second section picks up a batch of services and performs dependency validation and integration testing before going to Prod. "I think a lot of the problem is we are still thinking of 'Releases'. The principles behind Continuous Delivery is that you are continuously making small changes to the system that have automated tests to validate code and system (as well as other automated controls to insure quality) that are then continuously promoted and released. This of course is a huge culture change to IT and to the Business. A 'Release' strategy is not Continuous Delivery and will always have these balancing issues." A very astute observation that we are unfortunately not seeing made by many people at this point: even though a Continuous Delivery pipeline may appear to be "just an accelerated release process", the goal state in terms of how IT and the business interact with the customer can be quite different. We certainly believe that working towards hypothesis-driven development, incremental change and continuous customer engagement cycles are worthwhile, but these can indeed involve a significant culture change that is challenging to bring about irrespective of the state of the underlying (delivery) tooling. We know there is good evidence that this approach works and that the challenges involved in effecting the required culture change are worthwhile, but that does not in any way make the transition easier. What we as XebiaLabs try to contribute is not just partnership in building out the vision of the desired goal state (which may go all the way to a full CD philosophy or stop some way short of that!) and a incremental approach to getting there, but also tooling that guides improvement and makes benefits clearly apparent. In our view, it’s no use asking real-world organization to "boil the Continuous Delivery ocean" before our tools can deliver any benefit: our central aim is to allow you to get started today with your current process and improve that process guided by metrics and effective visualization of benefits achieved. Speaking concretely about releases, this means allowing you to start with your current release process, with a mix of automated and manual tasks, variation from one release to another and changing scope and frequency. Based on automated value stream mapping to pinpoint "troublespots" in your process, you can incrementally replace manual tasks by automation and move toward a more regular and standardized pipeline. Reporting and analytics help document at each stage in the transition how investment in automation and process improvement has resulted in increased throughput, lower failure rates or whatever other metrics you are aiming for. The bottom line for us is: whilst we firmly believe that the philosophy of Continuous Delivery can provide tremendous value to organizations across all industries, every business should ultimately make their own decision about how much of this thinking they want to adopt based on their particular business need. Ultimately, Continuous Delivery is also a means to an end rather than an end in itself, and we want to ensure our tools allow you to go as far along this path as makes sense for you.