How DevOps Teams Can 'Shift Left' and Shift Right' Their Way to an Effective Continuous Development Model

These days, software delivery can feel like a contra dance. DevOps teams  are told that they need to "shift left" or to "shift right." They're also instructed to pursue "continuous feedback loops" or other circular processes. Is all of this talk about shifting left and shifting right valuable? Meaningful? Or are these concepts mere buzzwords that lack real meaning?

The short answer is that, no, they're not buzzwords. However, it can be confusing to apply shift left and shift right in a meaningful way. It's easy to get lost in the weeds amid all of the talk about shifting left and shifting right.

Let's take a closer look at what shift left and shift right mean, and how DevOps teams can embrace these concepts to achieve real innovation through continuous development and software deliver.

What Is Shift Left?

Put simply, shift left refers to the concept of performing a given process earlier in the software delivery chain. In other words, if you envision the delivery chain as a pipeline that starts with development on the far left and ends with production release on the far right, the further the process is moved left, the earlier it can be performed.

The driving idea behind shifting left is that by performing a process earlier in the delivery chain, you can detect and fix problems more easily. If you wait longer, you face a higher risk that fixing one problem within your application will require you to modify other parts of the application because they depend on the thing that has caused the original problem.

What Can You Shift Left? Testing, Security and More

When you hear people talking about the shift-left concept today, they're usually discussing either software testing or IT security. These processes are obvious candidates for shifting to the left. Software bugs and security vulnerabilities tend to be exponentially easier to fix when DevOps teams catch them early.

However, the shift-left idea can be applied to any type of process that occurs within the delivery chain. Data management, software monitoring and even software marketing could be moved to the left, too.

OK. So, What's Shift-Right?

If you shift security, software testing and everything else to the left, you run the risk of neglecting the parts of your delivery pipeline that come later.

For example, if you prioritize performing software tests such as unit and integration tests early in your pipeline, you may not have many testing resources left to devote to user acceptance testing (UAT) or other forms of testing that typically come later. That's a problem, because cutting corners on UAT could mean that software quality issues that slipped by your earlier tests remain undetected after your software is in production.

The shift-right concept was conceived to address this issue. As you might imagine, shifting processes to the right means performing them later in the delivery pipeline. In many cases, this specifically means taking processes that typically happen before application release and moving them into production, to help you catch post-release issues before end users notice them.

Shift-right is not a term that you hear as frequently as shift-left, but shift-right is becoming an increasingly common part of the software delivery conversation.

Shift Left and Shift Right Really Mean "Continuous"

When people start talking about shifting left and shifting right, it's easy to assume that they're spouting buzzwords without any real meaning. After all, if you're being told that it's important to shift left and to shift right, what are you actually supposed to do? You can't move in opposite directions at the same time.

That's a fair criticism, I think. While it's easy to recognize the value of performing a process earlier or later than you typically would, the problem with terms like shift-left and shift-right is that they imply that moving a process entirely to the left or right of the delivery chain should be your top priority.

In reality, what most DevOps teams should be doing is striving to make processes like testing and security continuous. Processes that are currently performed in the middle of the delivery chain should be extended so that they start earlier and end later. That's the point that the shift-left and shift-right conversation is really trying to get across. But it's easy to overlook that idea because the terms shift-left and shift-right are easy to misinterpret.

No Process Is a Monolith

It's worth noting, too, that the processes that you would typically want to make continuous are not monolithic in nature. Keep this fact in mind when stretching these processes across your delivery chain.

For example, software testing is not a singular process. There are several different types of testing, some of which lend themselves more than others to shifting to the left or the right. As noted above, basic tests like integration and unit tests make sense to move the left of the delivery pipeline. On the other hand, it wouldn't really make any sense to do integration testing in production; instead, more complex tests, such as UAT, are suitable for shifting to the right.

The same is true of IT security. If you want to do shift-left security, you might start by having your security engineers collaborate more closely with developers so that code is written securely at the start of your pipeline. Meanwhile, other types of security operations, like hardening runtime security defenses, could be shifted to the right. During all of this, of course, the pre-release security checks that normally occur around the midpoint of the pipeline should remain intact.

Conclusion

Shift-left and shift-right are both valuable concepts, but DevOps teams should not embrace them in isolation. Instead, think of shift-left and shift-right as steps that you can take to make core software delivery processes like testing and security continuous across your pipeline. Continuity is the real goal.