https://www.flickr.com/photos/hikingartist/23669845634

Top 5 Roadblocks to Continuous Delivery and How to Remove Them

- Updated March 16, 2018

After speaking with different teams, I’ve noticed many folks trying to get Continuous Delivery deployed in their workflow. They understand the benefits but can’t get started. Here, I’ll explain the problems I commonly see and how to fix them.

 

1. Wrong Culture

As I mentioned in an earlier post, cultivating a DevOps culture is the most important first steps to moving towards Continuous Delivery. It is also one of the more difficult steps….and the one that teams tend to skip!

Here are some signs to look for to decide if your team’s culture isn’t ready for Continuous Delivery yet:

  • Code is often developed without considering Operations concerns like monitor-ability, scalability, or reliability. Continuous Delivery requires Developers involvement in the entire Software Lifecycle — and that includes Production maintenance.
  • Operations teams are inflexible with heavy process in place that prioritizes reliability over anything else, that includes Time To Market. If access to Production feels like a severely walled-off garden, then teams aren’t ready for Continuous Delivery because it requires balancing speed of delivery and making healthy trade-offs to reliability.
  • There are no clear owners for process improvements. DevOps is all about continually improving the product development process. If there are no owners, then it’s likely that this is not a priority for the team. Continuous Delivery is an investment and improving the workflow needs priority before progress.

How to fix this?  Invest in researching and understanding DevOps culture.  My mentioned article on DevOps is a good starting off point.  Once that’s done, Continuous Delivery will be a natural next step.

2. There’s No Tests

Continuous Delivery can not exist without automated QA and automated QA requires programmable tests. This is because Continuous Delivery is a balancing act between Development concerns (features, time to market, speed) and Operations concerns (reliability, security). Making code deploy continuously and automatically into Production environments is a boon for speed but sacrifices reliability. Automatically testing an application before deployment is necessary for re-balancing the equation.

However, if no tests exist for an application, then building a Continuous Delivery system is problematic.

Before proceeding with Continuous Delivery plans, write test suites for the application.  This includes unit, functional, smoke, and integration testing.

3. Application is not Testable

Sometimes the cause of a lack of tests is the inability to test or configure an application.  What this means is an application can not move easily through different environments.

For example, consider a frontend application that depends heavily on external web APIs. How can a codepath be tested in a local environment if it makes changes to an external API?  What if that API is not sandboxed or the codepath depends on an API response that’s only available in Production?  This happens very often.

Other examples include hardcoding values that are configurable, special deployment scripts that severely change how an application runs depending on the environment, or special networking rules that only apply in certain environments.

If you find yourself developing a Continuous Delivery system on an application like this, avoid taking shortcuts!  All of these scenarios have solutions such as Mocking an API, giving your team clear guidelines on what variables to support in an external Configuration store.

One of my favorite solutions for tackling these kinds of problems is to create a collaborative team of Developers and Operators. This is because many of these challenges are solvable by both Dev and Ops perspectives which is how tools like Terraform and Packer developed.

4. Software Lifecycle is Misunderstood

Another misfortune I often come across is that the team implementing Continuous Delivery does not understand their own end-to-end Software Development Lifecycle. Some questions that need answered before a Continuous Delivery attempt is successful:

  • How are ideas generated?
  • How are ideas turned into projects that are then assigned to a team?
  • How are teams formed?
  • When does code get developed to carry out those ideas?
  • How is that code validated?
  • How is that code deployed to customers as a finished product?
  • How is that product maintained after deployment?
  • How does the success (or failure) of the product feed back into the people generating ideas?

If these questions don’t have very clear answers, then it is time to pause the Continuous Delivery implementation and do some analysis of your team’s process. The most successful Continuous Delivery setups I’ve found are the ones that effectively model their team’s own workflows.

To move past this roadblock take the questions I listed and do some interviews to get these answers.  Then, use a visualization tool like LucidChart to diagram the process out. This is your Continuous Delivery map.  Use it to design the automation, scripts, and tools that improve the mapped out process.

5. Engineering Expertise isn’t There Yet

Continuous Delivery is an advanced technique that can cause many teams to stumble. Even on small products, there are many moving parts and many different approaches, opinions, and tools. It is overwhelming and time-consuming to tackle without prior experience. If the previous four Roadblocks aren’t an issue, then a lack of Engineering Expertise is likely your last Roadblock to adoption.

Implementing a proper Continuous Delivery system is best left to experts and is a good project for temporary outside help. Consider an agency that specializes in DevOps tooling and building custom solutions that fit your team’s process and culture.

 

Continuous Delivery is a tricky thing to get right. Stick with a DevOps perspective and plan a vision for your implementation. Do that and keep an eye out for the Roadblocks I mentioned and you’ll vastly improve your Time-To-Market without sacrificing your application’s stability. After all, it is about customers and giving customers what they want at a faster pace without sacrificing quality is the quickest path to making them happy and delighted.

 

Acknowledgements:

Feature Image by Frits Ahlefeldt: https://www.flickr.com/photos/hikingartist/23669845634