In a survey conducted a few months ago by XebiaLabs, implementing Continuous Delivery (CD) was listed as one of the key initiatives for many enterprises. CD’s ability to rapidly and repeatedly bring feature improvements to market, aligns naturally with business initiatives to accelerate time-to-market and stay a step ahead of the competition, while maintaining quality. It also helps to meet the expectations of today’s “always-on” consumer, who has come to expect simple, one-click installation of applications that update automatically and regularly.
However, putting CD into practice can be challenging, to say the least. Particularly in the context of the existing development and release environment in a large enterprise. In this article, I’ll examine some key challenges that we’ve encountered when helping clients introduce CD and related automation, along with some helpful suggestions on dealing with them.
Challenge #1 Massive, monolithic applications
A key aspect of CD is making small, incremental changes to an application, to enable fast feedback and faster fixes. Large, tightly-coupled applications with multiple components that need to be compiled, tested and deployed together are tough to update incrementally, leading to long development, test and deploy cycles. Quality control and root cause analysis is harder too, as many changes are being implemented at the same time. Also, as each release procedure needs to differ slightly, it is hard to create a standardized delivery pipeline and benefit from the resulting increase in reliability.
When faced with this challenge in the past, we have tried to initiate a workstream to incrementally break out components of the application into separate modules. These can then be built and deployed independently, allowing for faster feedback cycles with smaller changesets.
Challenge #2 Minimal automation
We shouldn’t be automating for the sake of automation: manual activities aren’t “banned” from a CD pipeline on principle. However, a high percentage of manual steps will likely slow down your delivery pipeline and increase the chance of errors, thus preventing you from being able to scale your CD implementation. In order to meet your throughput and consistency goals, it is usually required to either automate a bulk of the manual steps in your delivery process, or replace them with suitable alternatives.
It is important to treat this automation effort as seriously as any other development effort, applying appropriate design, coding and testing practices in order to avoid ending up with an impossible to maintain “ball of mud”. The Infrastructure as Code movement has made significant steps in this area, for instance promoting test-driven development of provisioning and deployment automation and providing supporting tooling.
Challenge #3 Limited environments
A limited pool of shared test environments increases the risk of bottlenecks during your CD implementation. You would need to “block” or “reserve” an environment to avoid two pipelines running side-by-side from attempting to deploy and test in the same environment. Measures also need to be taken to prevent one pipeline blocking an environment for too long, or for one pipeline to always just beat the other to the required environment, leading to “starvation” for the other project. Furthermore, an interesting data point from the aforementioned survey is that misconfigured or “broken” environments, that have been unexpectedly modified by previous teams or test runs, are one of the leading causes of deployment failures.
If you plan to be running delivery pipelines at scale, a dynamic pool of available, “clean” target environments is required. Private, public or hybrid cloud platforms, coupled with provisioning and configuration management tools, allow you to grow and shrink this pool automatically and on-demand.
Challenge #4 Enterprise” release management
As soon as we approach QA or production in most enterprise environments, an increasing number of release management requirements must be met -- creation of a change ticket, placing the change on the agenda of the next Change Board meeting, receiving Change Board approval, confirming deployment windows etc. etc.
How do you integrate such requirements into your delivery pipelines? Some possibilities:
- Simply cap all delivery pipelines at the test stage, before running into any release management conditions. The goal is typically to take CD further than just test environments, though.
- Integrate the various release management steps into the pipeline, e.g. by manually and, eventually, automatically creating and scheduling a change ticket, or by automatically setting a start time on the pipeline’s deployment phase from the change management system.
- Revisit the need for certain change management conditions. The origin of such practices is typically to ensure that only changes of an approved level of quality and stability make it to production – precisely the level of quality and stability that prior stages of a delivery pipeline are intended to verify.
Challenge #5 Managing multiple “custom” pipelines.
In a large organization with a diverse service portfolio, spanning different technology platforms, departments, customers, and teams there will be many pipelines to manage as you scale your CD implementation. If every pipeline ends at a different stage in the delivery process, it would be difficult to compare metrics such as cycle time, throughput or percentage of successful executions
A large set of pipelines is easier to manage if each one is based on a standard template. Standardized pipelines also allow for more meaningful comparative reporting as well as providing useful feedback that can be applied to other pipelines. Templates can be as simple as a shared Wiki page but can also supported by CD tools such as Go. The number of templates you should start with depends on the variation across your service portfolio; one per technology stack is often a useful starting point. Over time, you will hopefully be able to consolidate towards just a handful of pipeline types.
Challenge #6 Ownership and security
Automated delivery pipelines span multiple teams of the IT organization, something that is especially highlighted when pipeline stages fail and it’s hard to find who needs to fix it. Every pipeline stage needs to have an owner(s) tasked not only with fixing problems and getting the delivery stream running again, but also with contributing to feedback-driven improvement of the pipeline as a whole.
Since visibility into the state of the entire pipeline is important for all stakeholders, it is important that any orchestration tool considered offers a suitable security model. For example, developers will probably need to examine the results of a functional test phase to help identify the cause of test failures. However, they should not be able to disable or modify the configuration of the functional testing step.
In Summary
Analyzing which of the common challenges to putting CD into practice apply in your situation should be a first preparatory step in your implementation. Gain an accurate picture of your current baseline, structure your implementation in measurable phases, and then work on dealing with these challenges to clear the way for your first delivery pipelines with defined roles and responsibilities for each phase. Mitigating any challenges that you identify early in the project cycle will help your implementation progress smoothly and help you address future challenges. Your CD implementation will then be on the way to providing faster releases, more reliable feature delivery and steady improvement driven by quicker feedback and better insight.
Guest blog by Andrew Phillips, VP of Product Management for XebiaLabs
