One of the most popular terms bandied about in DevOps is “shift left”. I was at a workshop last month at IBM InterConnect conducted by Sanjeev Sharma and Mustafa Kapadia. They put on a great workshop which was a preview of an exercise they perform in the field for clients. A central theme of their talk was the idea of shifting left to address issues earlier in the development process.
iBM, Sanjeev and Mustafa (both of whom write here on staging-devopsy.kinsta.cloud) are not the first or only people who speak about shifting left in DevOps. Derek Weeks of Sonatype wrote a blog post about it back in September of 2013. Almost a year to the day later, Dibbie Edwards of IBM (and the focus of a good article by George Hulme) wrote a good article about shifting left with continuous testing. Andrew Storms wrote a post here on staging-devopsy.kinsta.cloud some months back about shifting security left in DevOps. Indeed shift left is generally regarded as a basic foundation of DevOps.
Before we dive into what this means to you, we should make sure that we all understand what shift left really means. For me looking at a standard flow of the development/deployment process is the best illustration of this. I think Andrew Storms used a good one in his article, so let’s repurpose it here:
Pay no attention for now to the before DevOps or DevOps rays for now. Take a look at the top line which is the pipeline. You can see the flow of an app from plan to code and all the way to operate. The flow runs from left to right. At its simplest shift left moves tasks further left. Security, continuous testing, continuous integration, continuous delivery are all shifted left.
In doing so potential issues are addressed earlier in the lifecycle. What is this a good thing? A chart from Dibbie Edwards article gives us the obvious answer:
As can be seen the earlier you can get to issues, the cheaper it is too fix them. That alone is a reason to shift left. But also concepts such as addressing security issues before it effects your customers is appealing. The same can be said for many other functions you can shift left.
For me though the question is by shifting everything left, do we just wind up with a big pile at the very left? How do we prioritize all of these left shifted functions? You can only shift left so far before you come to the beginning of the time line. This is not the birth of the Universe where you had a big bang which defies the laws of physics.
At some point can you shift too much left? This is a question I am going to pose to Sanjeev and Mustafa. I also pose it to you the reading audience.
I recognize that the concept of shifting left is not so efficient that everything that can be shifted is in fact shifted left. But as we get more efficient, more and more tasks are left shifted in the process. At what point do we reach the point of diminishing returns?
How do you feel about this? Can we shift too much left? I am interested in some of the different views on this. I am a big proponent of shifting security left, but are there other priorities?
Let us know your feedback.
Thanks for raising this important question… The ‘piling up on the left’ concern is a real possibility. To overcome, an organization must adopt good practices in automation, decision frameworks for prioritizing investments, and LEAN techniques like kanban or value stream mapping to identify bottlenecks and flow issues. Otherwise you’re adding to the ‘pile of to-dos’ without implementing, closing and reducing it. I’d assert that nearly every good software engineering practice stems conceptually from shifting left. For example, Why do we test at all? Why do we model or simulate performance loads? Why did continuous integration or service virtualization emerge? Why do we do regression or smoke test on code commit or check-in? All because we don’t want all kinds of ‘piling up on the right’ — discovering problems later in the cycle, in production, and expensively as Alan pointed out in the piece. How do we prevent ‘piling up on the left’? Pinpoint bottlenecks and flow issues, prioritize (investing and) resolving them, automating, and shifting left to build or test environments. Lather, rinse, repeat. This places a premium on good technical practices & skills, crisp decision making, software org leadership, and requires systems thinking. Hope that’s helpful… Peter Spung, @paspung
Peter great comment and great ideas here. Would you like to expand this into a full post that we can put here on staging-devopsy.kinsta.cloud? Let me know and write me at editor@devops.com and we can get it posted.