What do DevOps organizations need to do to shift left?


Posted by admin - July 18, 2016

The concept of "shift left" is a key component to successful DevOps, continuous integration and continuous deployment initiatives. To "shift left" simply means to conduct more testing earlier in a product's lifecycle – i.e., move it to the "left" on a left-to-right flowchart representing the journey from planning, development, to deployment and beyond. The goal of shifting left is to deliver applications faster with less effort/cost.

The relationship between shift left testing and DevOps automation

What is the point of doing a leftward shift? What is the point of doing a leftward shift? There are several good reasons for organizations to consider re-architecting their development and testing processes to enable earlier testing:

  • Defects become increasingly expensive to fix the later they are discovered in the application lifecycle. A chart from IBM Systems Sciences Institute on the relative costs of such bugs demonstrated that a flaw discovered during testing costs 15 times as much as one found during design, while one revealed during maintenance costs a staggering 100 times as much.
  • It is easy for teams to become bogged down by long backend test cycles. Regardless of how quickly they might move through the project's sprints, they could still end up not being able to ship what they had worked on, and instead needing to go through a big "end game" push. This is often both a technical and cultural issue, and one that can cause big delays as well as budget overruns.
  • DevOps success is contingent on the ability to move significant parts of the software lifecycle leftward. Pre-DevOps pipelines often divided up tasks between dev (responsible for coding, testing, etc.), QA (responsible for pre-deployment testing), and ops (deployment and operations), but DevOps seeks to collapse the distinction between these silos and enable continuous testing and deployment by cross-functional teams.

"[T]he more effort that is shifted left or earlier in the process, the better," explained Derek Weeks of Sonatype. "When you can make design and architecture decisions early, when you can select the right component from the beginning, when you can identify problems early, when you can fix bugs and vulnerabilities, early, etc., you can improve your software delivery capability, you can improve the reliability and trust of your applications, and you can reduce your development and maintenance costs."


x_0_0_0_14129341_800The longer it takes to discover software flaws and defects, the more expensive it is to address them.


Keys for shifting to the left

If shifting more tasks to the left is the ideal, let's look at some key building blocks that will give organizations a practical way to start shifting left.

Automation is a key component to shifting left because it reduces the effort and time required to perform testing, configuration, and deployment activities. Continuous integration tools like Jenkins allow organizations to begin automating the overall build and test process - kicking of automated builds and tests when new code is checked into a source repository. Test automation tools and platforms allow creating test automation flows for unit, integration, performance, regression, and acceptance testing. Configuration management tools like Puppet, Ansible, and Salt-stack allow automating the configuration and deployment of software and infrastructure to make the build, test, and deployment process more repeatable.

There are now-familiar solutions such as Jenkins, which via its large system of plugins can be used for running tests, building Dockers containers and so on, along with platforms such as Quali CloudShell. With CloudShell, users can tap into a reservation and scheduling system, a Web-based self-service portal and a drag and down interface to support DevOps automation in conjunction with Jenkins, Puppet and other utilities.

"Automation has to be an integral part of the leftward shift."

Container technology offers a unique way to shift development and test activities to the left. Containers allow multiple applications and their dependencies to be bundled in a container that can be easily created or destroyed on the fly without any additional automation, making it easy to create and store predefined application environments for development and testing. Because containers make it easier to create re-usable, multi-tier application environments without a ton of automation harnessing, they allow dev and test engineers to perform more integration and advanced test activities earlier in the dev/test cycle.

Cloud sandboxing

Sandboxing fills a gap that is not addressed by simple automation or containers in terms of shifting left. For many organizations, the complexity of their applications and infrastructure is growing at a rate that makes spinning up realistic or "production-like" environments early in the dev and test cycles extremely difficult. Shifting left demands creating realistic application and infrastructure environments as early in the dev/test process as possible, but hybrid cloud applications, dependencies on legacy infrastructure, new network architectures and technologies, and application support technologies like service virtualization all make modeling, maintaining, and managing these kinds of realistic dev and test environments very difficult.

A sandbox is like a container, but for the infrastructure rather than the application. A cloud sandboxing tool such as CloudShell gives developers and testers the ability to model complex application and infrastructure environments which can then be shared as blueprints with other users and deployed on the fly. Integrations with other DevOps tools allow sandboxes to be triggered automatically. For example, Jenkins can trigger an entire sandbox for testing a complex hybrid cloud application in one call rather than having to rely on a complex automation script.  Ultimately, the sandbox allows teams to model different on-premises, legacy, and public cloud infrastructures to ensure that their applications work as well as possible and as early possible in the dev/test process.

The takeaway: Shifting to the left is an important part of the DevOps transformation. The concept entails earlier and more frequent tests, at the left side of a left-to-right continuum representing an application's lifecycle. Using tools for continuous deployment, configuration management and cloud sandboxing can make shifting left a reality.

  • Posted by admin on July 18, 2016
  • About Author:

Topics: DevOps, Sales Demo

Recent Posts

3 Ways to Maintain Business Continuity During the COVID-19 Outbreak

read more

One Simple Secret to Reducing Your Sales Cycle Times

read more

How To Avoid Overspending In Your Cloud Accounts Without Slowing Innovation

read more