Situations in which Continuous Delivery Could Potentially Lead to Problems

Although there are many advantages to deploying small changes very frequently (Fowler 2006), using continuous deployment can also lead to problems in the development process.

Integrating the process into existing projects can cause fear-driven development in which team members hold on to unreleased code as they are afraid of breaking the build and slowing down the process (Bugayenko 2014a). Also, if the existing codebase lacks automated tests the barrier to entry is high, as the team has to invest time in test coverage (Humble and Thönes 2015) rather than new features that add value to the customers (Bugayenko 2014b).

Long-running tests and a high commit frequency can lead to builds queuing in the pipeline (Mayer 2013). If a builds fails it is more difficult to repair as the later changes must be reverted or adapted which increases time to fix and stalls the whole team (Humble and Farley 2010). This can also be an issue if release depends on an external approval process, e.g. the AppStore (Fitz 2012).

In a project that makes heavy use of external dependencies such as other services, automated tests are difficult to achieve because these dependencies might not have a test environment that other teams can use that is quickly fixed if it breaks (Lewis and Thönes 2014). Failing builds due to malfunctioning dependencies also introduce backlog into the build pipeline.

Continuous downtime can result from frequent deployments if the available infrastructure is not sufficient to perform rolling updates to avoid downtime (Smith (Atlassian) 2014). While this problem can be solved by spending money on infrastructure, there are other related issues that cannot be mitigated; processes that run before each deployment such as emptying caches can temporarily affect performance which may negatively impact revenue. The higher the frequency of deployments, the bigger the impact of these temporary effects.

Resources

• Bugayenko, Yegor. 2014a. “Continuous Integration Is Dead.”

http://www.yegor256.com/2014/10/08/continuous-integration-is-dead.html.

• Bugayenko, Yegor. 2014b. “Why Continuous Integration Doesn’t Work.”

http://devops.com/blogs/continuous-integration-doesnt-work/.

• Fitz, Timothy. 2012. “The Hard Problems of Continuous Deployment.” Presented at the October 9 ’Continuous Delivery : NYC’ meetup.

http://www.slideshare.net/TimothyFitz/the-hard-problems-of-continuous-deployment.

• Fowler, Martin. 2006. “Continuous Integration.”

http://www.martinfowler.com/articles/continuousIntegration.html.

• Humble, Jez, and David Farley. 2010. Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation. 1st ed. Addison-Wesley Professional.

• Humble, Jez, and Johannes Thönes. 2015. “Episode 221: Jez Humble on Continuous Integration.” Software Engineering Radio – The Podcast for Professional Software Developers.

http://www.se-radio.net/2015/02/episode-221-jez-humble-on-continuous-delivery/.

• Lewis, James, and Johannes Thönes. 2014. “Episode 213: James Lewis on Microservices.” Software Engineering Radio – The Podcast for Professional Software Developers.

http://www.se-radio.net/2014/10/episode-213-james-lewis-on-microservices/.

• Mayer, Dan. 2013. “Thoughts on Continuous Deployment.”

http://www.mayerdan.com/programming/2013/08/04/thoughts-on-continuous-deployment/.

• Smith (Atlassian), Steve. 2014. “Practical Continuous Deployment.”

http://blogs.atlassian.com/2014/04/practical-continuous-deployment/.