Challenges in Adopting Continuous Delivery

Over the last few years, continuous delivery has been one of the most talked-about development methodologies. Delivering your application features quickly to the market (as soon as they are ready) sounds like magic.

The idea of continuous delivery was developed and shared by Martin Fowler. He described the background of the practice this way: “Every developer integrates with everybody else’s work frequently. And, if something has failed, nobody has a more important job than fixing the backstage”.

Ever since there have been multiple multiple interpretations of continuous delivery but in simple terms, Continuous Delivery is a practice, which automatically and continuously releases the application (changes) to production environment after successfully passing all automated tests and quality checks.

This article points at some confounding factors that might impact the adoption of CD practice: i.e. despite application is potentially production-ready, there are still factors that de-motivate organizations to continuously and automatically ship the code from development to production

Lack of fully automated test

Many teams think that we cannot automate everything or it might take a lot of workload and time for organizations to have a set of fully automated testing. Many teams see automated tests, especially user acceptance as high effort and low gain. Some think there has to be manual intervention for assessment of results as it would bring more value and increases confidence in code quality.

Manual Quality Check

Many teams feel, though automation is critical to Continuous Delivery, manual tasks are sometimes unavoidable. For example, teams experience it very easy to continuously delivery in lower environments like QA or staging, but when it comes to production lot of additional verification and checks are required. The most common manual task is a review of various checklists and physical approval required by different stakeholders. Traditionally there is always that bit of extra caution around production environments which requires having another round of sign-offs which can de-motivate team accepting automatic delivery. Conducting manual check and confirming the changes before each release

can be a big challenge for frequent and automatic deployment. Organizations are not willing to automate all (for various reasons like, due to lack of trust in existing tools) and believe that manual quality checking brings much more values to them. Organizations feel Deployments to production need a human trigger. it feels safer to look closely to the metrics during the deployment process

Business-driven delivery

In some applications, the development teams are not able to immediately deploy every change to the production environment, despite passing all the tests and quality checks. This could be because deploying to production is considered as a business decision, which had to be made by management or financial units. In other words, development team members have little control over production deployment.

Solutions are very tightly integrated with different vendors or different stacks

Solution deployment to production might require taking agreement and acceptance from different vendor teams. In such scenarios, individual teams are given some slots based on their delivery cycle or their priorities and they have to obey with those slots.

Many teams have deployment processes that have formal bureaucratic checklists prior to deployment due to multiple integrations. Solutions come from various teams and in different stacks and having continuous delivery to make eco-systems work across the vendors can be very difficult and hence teams might prefer to involve manual checks

Deploying software changes on a continuous basis necessitates continuously deploying all dependencies. Continuous delivery becomes very difficult when you want to automate deployment for a complex stack. Sometimes teams have challenges to get everything working within one task. To have all dependencies of your deployment ( especially if you have legacy applications) as continuously and automatically delivered, you need to deploy all these things together and everything should work after deployment and you always face one or two things more difficult.

In such scenarios, teams prefer to have a manual process to allow coordination with other vendors

Lack of automated provisioning of environments

Teams often found themselves struggling with provisioning or configuring production environment and this is perceived as a severe roadblock to Continuous Delivery. Manual configuration of complex software, particularly when there is a tight coupling between software and hardware represents a significant obstacle to Continuous Delivery.

Without automatic provisioning, there is always a challenge on how to keep development or staging environment in synchronization with the production environment. Because you can’t have the same testing environment like a production environment, for example, the network is different you need to invest in automation of these environments.

Conclusion

While challenges to adoption of Continuous Delivery are inevitable, the business value it brings far out-weights them and so teams must be encouraged to find tailored solutions to achieve it. The successful players in the industry have adopted continuous delivery in their development a long time ago. As Martin Flower said, “Frequent deployment is valuable because it allows your users to get new features more rapidly, to give more rapid feedback on those features, and generally become more collaborative in the development cycle”.

Continuous Delivery is a way to break the silos between teams, creating a user-oriented, useful application.