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.
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:
"[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."
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.
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.