Expedite the Handoff from Dev to Test: An Interview with Gary Gruver (Part 1)

In his book, Applying Agile and DevOps at Scale, Gary Gruver talks about the differences between the application deployment pipeline of a loosely coupled architecture vs a tightly coupled architecture typical of large enterprises.

In loosely coupled architectures, release trains achieve quality validation independently. He uses multiple parallel train tracks to illustrate this delivery independence. And parallel lines never cross, right? Nice and clean.

The reality for the enterprise though, is a large, tightly coupled architecture with multiple interdependent pipelines. While these pipelines may run in parallel initially, eventually they converge as the test environments become increasingly complex to reflect the final production state. If one pipeline gets stalled, the flow of the entire release is jeopardized. Not so nice, not so clean.

We sat down with Gary recently to discuss the challenges of application delivery in the enterprise. Since we were talking with a DevOps guru, it’s no surprise the main topic was pipeline efficiency. We specifically focused on the dev to test hand off, as well as test environments for our interview; topics near and dear to our hearts as our customers tell us these are massive but ironically often unrecognized bottlenecks.

The World Quality Report highlights the breadth of this challenge:

• 42% identified “test data and environment availability” as the main challenge in achieving desired level of test automation.

• 46% of enterprise customers cited “lack of appropriate test environment and data” as key challenges when applying testing to agile development.

Test automation may be adopted, agile or scaled agile methodologies honed, but if test teams can’t get access to a properly configured test environment the delivery flow stops.  And waits.  Fresh from recent SAFe training, I was bursting with soundbites about process improvement and ready to talk efficiency…

• “Any improvement before or after the bottleneck is a waste of time”1

• Optimizing a component doesn’t optimize the system.

• A system can’t evolve faster than its slowest integration point.

In your book Starting and Scaling DevOps you state:

“There is nothing more demoralizing for these small, fast moving teams than having to wait to get an environment to test a new feature or to wait for an environment in production where they can deploy the code.”

What are some of the key challenges in getting a test environment up and running?

GG: “Test teams face a lot of constraints with regards to test environments… How do I make sure everything is configured correctly, deployed correctly, ready to test, the database is synced… This can be very challenging. They end up running tests that aren’t passing that have nothing to do with the code, but instead are a result of a test environment issue.

You want to find defects as close to the developer as possible to get them fast feedback. However, it’s backwards for a lot of orgs that do a majority of their testing in complex test environments. Once you get code into a large enterprise test environment the ramification of failure is far more profound. A defect can impact a majority of your delivery pipeline… yet not be at all associated with code.”

Talk a little about the process of improving efficiencies when testing in a complex enterprise environment.

GG: “First thing we look at is cycle time… the time it takes from business idea to working code. When you force an organization to build and test on a more frequent basis they find issues that have been a problem for years. I ask them to map out deployment pipeline… dev, unit testing, regression testing, UAT, performance testing, etc. Then we try to map out how long does it take for code to flow from dev to the environments to production.”

From Starting and Scaling DevOps in the Enterprise:“Improving cycle time is important because it drives feedback times to minimize the amount of work on features that customers won’t use, that won’t work with other code, or that won’t work in production.  The reduction in cycle time minimizes the time different groups across the deployment pipeline invest in things that won’t work together.”

GG: “To really develop a solid, streamlined testing process though, the metrics that I try to capture at a customer are typically hard for them to get. As opposed to measuring productivity, I’m more in the mode of trying to identify and highlight waste to take it out of the system.”

From Starting and Scaling DevOps in the Enterprise:“Developers waste time triaging defects that were thought to be code but ended up being issues with data, environments, and deployments…The QA org wastes time and energy testing on a build that has the wrong version of code, is in an environment that is not configured correctly, or is unstable for other reasons…The release team wastes time trying to find all the right versions of the code and the proper definition of the environments, and getting all the right data in place to support testing…”

GG: “Lots of orgs spend more time and effort getting the big, complex enterprise environments up and ready for testing than they do actually writing the code.”

And there it is. The perfect soundbite to stop with. Remember we said above that we find managing test environments to be a massive but ironically unrecognized bottleneck? In our next installment from our interview with Gary, we’ll look at his approaches to test triage, additional metrics, and the importance of getting test environments under version control as a starting point in any DevOps journey.

In the meantime, check out how Plutora Environments helps delivery teams schedule, manage, and maintain test environments. We’ve helped customers increase test environment productivity 140%, and better predict and remediate environment contentions.Watch the on-demand webinar with Gary Gruver: Continuous Delivery Pipelines: Metrics, Myths, and Milestones.1The Goal, by Eliyahu Goldratt.