Continuous delivery is an illusion. That doesn’t make it insubstantial: illusions can have a tremendous impact, Louis Evans, Product Marketing Manager, Delphix, reveals.

Take the first motion picture: the locomotive felt so real to first audiences that they fell from their chairs, screaming. But of course, the locomotive was an illusion, merely rushing past on screen.

A good magician, like a good inventor, will tell you that the secret to a powerful illusion is hard work on top of a good idea. But each knows the secret to truly wowing their audience, whether for a one-night-only show, or an ongoing relationship is the vast, complicated, hard-won machinery ticking away behind the scenes. Right now, continuous delivery provides that wow. It takes app updates from a customer stumbling block to a seamless benefit. It takes feature delivery from ‘maybe in a year’ to ‘is tomorrow soon enough?’ It allows development teams to wave their magic wands and transform the impossible into the effortless.

The heart of continuous delivery is automated testing

And, of course, continuous delivery is an illusion. Remember the locomotive leaping out of the screen? Every instant of its motion was its own little frame of celluloid. And the true magic was the process that bound each and every frame together, delivering them onto the screen with perfect timing. Continuous delivery is the very same sort of illusion. The steady stream of new features, new capabilities, and bug fixes must be created one by one by a vast army of talented developers – much like the thousands of talented stencilers who first brought colour to motion pictures. And the true heart of the process is the automated systems that support this army, and which ensure the coordinated delivery of its products to the end user.

As such, the heart of continuous delivery is the machinery of automated testing and deployment. It encourages teams to produce software in short cycles, ensuring that the software can be reliably released at any time. In order for these releases to be reliable, continuous testing is integrated into the software delivery pipeline, for immediate feedback on any bugs an update would generate. Then, when a proposed change has passed the automated tests, it is deployed to production automatically. This SDLC allows companies to achieve the business goal of truly responsive development. The team sees an opportunity, confirms the solution, and then delivers that solution to customers extremely rapidly.

Each stage of continuous delivery – develop, test, deploy – has its own technical challenges, but the testing step, in particular, poses a unique bottleneck.

Develop, test, deploy

In the development stage, developers primarily require code. Code is relatively lightweight, and can be managed through industry-standard tools like Github. Developers need their laptops, but in general code management poses a limited operations support challenge.

The deployment stage can be more challenging for ops. The newest version of the code must be deployed to a wide population of final platforms, which may vary in hardware, software, location, permissions, and so on. However, the target systems are at least those in ordinary use. The server the new page runs on or the smartphone that installs the application update are pre-existing systems, and they are managed by their users. So operations teams are not required to support specialised hardware to deploy.

Testing, on the other hand, combines the challenges of both of these stages. Continuous testing requires dedicated resources for developers and QA. But these resources are full-scale application environments, including not just code but data, operating systems, and even appropriate hardware. And because best practices encourage developers to write new tests for all new code, the amount of regression testing required for every code change can only grow. That means that testing must grow ever more parallel, or suffer increasing delays – and any delay in testing can undermine overall continuous delivery.

Test data to support continuous strategy

To preserve the continuous illusion, a development team needs on-demand access to scalable testing environments, including their data. Data, in particular, is often overlooked in test environment creation – but it must be delivered to every test instance. That means test data management (TDM) is an inescapable part of any successful continuous strategy.

Test data management refers to the process of creating, managing, and delivering production (or production-like) data to non-production data environments. Every organisation does it, but to achieve the sort of seamless efficiency that can support the continuous illusion, teams must adopt modern practices to avoid multi-stage, manual delivery chains. In legacy TDM approaches, developers and testers file tickets, and then they wait. Storage admins, DBAs, backup admins, security personnel, and other staff each have to spend a huge portion of their time servicing the ever-growing stream of tickets, handing off environment creation from one function to another. Meanwhile, developers and testers are left in the lurch, and continuous delivery grinds to a halt.

The most effective TDM practices will use a data management solution on par with other continuous delivery pipeline tools. The solution will be able to stand up data environments in minutes and at massively parallel scale. It will rely on production data and automatic security, rather than synthetic data generation or data subsets (both of which requires substantial up-front planning and cannot hit the full suite of edge cases). It will integrate readily with existing CD workflow tools, allowing data to be automatically provided whenever a test job runs.

Summary

In order to deliver the continuous illusion, every component of the continuous delivery pipeline must be operating at peak efficiency. By adopting a powerful TDM solution, you can tighten test cycles and deliver code faster, regardless of how fast your software timelines are today and enable your customer to sit back, relax and enjoy the magic of your products.

Edited for web by Cecilia Rehn.