When Continuous Delivery Needs A Pick-Me-Up

By now, you’re probably aware of continuous delivery and its wide adoption amongst large enterprise level companies such as Amazon, Facebook and Netflix. Additionally, when it’s discussed, it probably sounds like the benefits are endless – shortened software development life cycles and a reduction in cost, time and risk. Ah, the wonders!

So, where do things go awry? Surely, it couldn’t be where building and testing is concerned. After all, check out these before and after findings from Gary Gruver in his book “A Practical Approach to Large-Scale Agile Development: How HP Transformed LaserJet FutureSmart Firmware”: 

Before Continuous vs. After Continuous 

·      Build cycle time: 1 week -> 3 hours (10-15 builds per day) 

·      Commits: 1 commit/day -> 100 commits/day 

·      Regression test cycle time: 6 weeks -> 24 hours 

Seems pretty great, right? Of course it is! In fact, Gruver writes, ““There’s no way we could have been modifying 100K lines of code in the previous regime; you need continuous integration or continuous delivery infrastructure to allow teams to go fast.” 

It’s great, it’s beneficial, yada, yada, yada… Where, you must be thinking by now, does continuous delivery need a pick-me-up if it’s so amazing? Take a guess… It’s probably not where you’d think. 

Thought enough about it? 

Okay, here it is. Continuous delivery needs improvement exactly where it’s already adding improvements. 

Let’s dive a little deeper so you can better understand what exactly we’re trying to say. 

Currently, some companies we meet with that deploy a continuous delivery process incorporate test-driven development. In other words, they’re developers are both building and testing the software. Though it seems like a smart way to increase productivity and save on costs, it’s really not. 

It’s not a bad practice by any means, but think about it. The faster you push code and the quicker your release cycles are, the more testing becomes a liability. Is this really an area you want to risk, especially when your customers expect and demand a consistent experience and a high-quality product? 

By shifting your developer’s focus to testing, it takes them away from what they do best, which is creating and building software. What organizations that use the continuous delivery process need is help with testing. Instead of depending on their developers for testing, they should be utilizing a dedicated automated testing solution. 

In order to have a truly successful continuous delivery process, automated regression tests are required. Every time a build is deployed or existing code is changed, there should be software in place to execute a suite of automated regression tests. For example, with machine-learning platforms like Functionize, you can test very quickly. Since the platform is elastically scalable, you can run thousands of test cases in a matter of minutes. 

Now, imagine how many more builds are possible when your developers aren’t focused on testing as well. Not only will build cycle time decrease significantly, but so will regression test cycle time. 

At the end of the day, the benefits of having a continuous delivery process can be huge. However, implementing that process can also be quite challenging. Without proper tools and platforms in place like Functionize, expect testing environments to take weeks to set up. Additionally, if you continue to ask your developers to create and test, then be prepared for longer releases and less builds over all.