What is Shift-Left and how to use it in DevOps?

When I first began working in IT (I started as a QA Engineer), the product we were working on, was developed in a waterfall model. Requirements, Design, Implementing, Testing (you get the idea). The QA team did not have much to do at the beginning of the release cycle but they were always in deep waters by the end of the release. We had to take a lot of heat from the developers for finding bugs. This would create a lot of friction because we were the “bad guys” that stopped releases, made them work late, and wouldn’t approve the release and therefore, not publish it. It was toxic and not fun, surely never at the end of any release cycle.

With the introduction of Scrum and with that, the agile mindset (which was by far the hardest to learn), new teams were founded and old teams were dissolved. Members of the QA team were put into the new formed development team. The role of the QA Engineer changed; from executing tests at the end of a 3-6 month long release cycle to just-in-time testing, planning and implementing test-automation. (Yes, some of the QA Engineers even had to learn how to write code). In the beginning, we (my fellow QA engineers and I) focused on regression tests, later supporting developers with writing Unit Tests, adapting to a Test Driven Development mindset, and learning how to test properly. In some cases, we developed APIs and integration tests as well.

As sprints progressed, automation (foremost Test Automation) became a bigger role. We still had Releases (business is business), however. As the months progressed and we grew as a team, the releases became less chaotic, less stressful. The quality increased also significantly since we found the most critical bugs during the development process itself. We reduced releases from 1-2 weeks to 1-2 days. No night shifts, less friction, almost no blaming. We acted as a team.

This happened almost 13 years ago, I didn’t know of Shift-Left I’m not even sure if that term formally “existed” at that point in time.

So what is Shift-Left?

Generally speaking, Shift-Left is the practice of moving tasks, that are normally done in later stages, to earlier stages. Shift-Left testing (as explained above) has gained a lot of traction and popularity in the last few years. It is the process of moving test activities to early stages of development.

Are Unit-Tests already Shift-Left?

Test Driven Development is a key agile practice and helps to form a mindset of quality awareness and of prioritizing testing in the development process. However, the tricky part is the integration. Shift-Left testing focuses on this part. With automated tests such as regression-tests, integration-test, end-to-end-tests or even non-functional tests (like load and performance tests), we try to find integration bugs, regression issues, and performance problems as early as possible. This ensures that bug-fixing is less painful and more cost-effective.

Can Shift-Left reduce costs and test effort?

Yes and no. In the long run, we will reduce costs but more importantly, we will increase the overall (end-user) experience and quality. However, we will not reduce the costs or testing effort on the testing side of things. It will be necessary to increase the automation effort, to keep up with the implementation of new features as well as testing the existing part of the product.

This will only be possible with the right amount of automation. However, the goal in using this approach is to reduce costs. Costs that might explode when finding critical bugs in production, discovered by end-users. With the early test approach, we want to provide a safety-net, that helps us reduce the need for hot-fixes, “emergency-releases”, as well as rollbacks. So yes, it is possible to reduce costs in the long run, but not on the testing side.

Shift-Left and DevOps

Adopting DevOps practices helps to reduce friction between teams, mainly between Development and Operations teams, besides other teams like Security and Business. And guess what, it is possible to use Shift-Left in Design Thinking as well. This helps the different teams (e.g. dev, ops, sec) to understand business requirements fully. Equipped with this knowledge, the entire team truly understands what is needed, and they all can work forward to achieve the same goal. The focus is kept on implementing those features that will bring the most value to the end-user and which respect the needs of the business and market.

To tie everything together, a Shift-Left mindset can be used to approach the technical side of DevOps as well. Automation is a big part in a Shift-Left process. We can use it to implement CI/CD pipelines in a way that deployments of infrastructure and software are tested and validated right within their early stages.

While this is easier for applications that are “born in the cloud”, it is also possible for “legacy” applications.

For both types of applications, it remains applicable that you want a multi-stage concept (e.g. dev, test, pre-prod) which should be a scaled-down clone of the production environment. Infrastructure as Code (IaC) - a codified version of your infrastructure - should be used to set up the infrastructure automatically with the help of CD pipelines. A Development team can test the infrastructure and its configuration as well as the deployed software in that infrastructure right at the beginning of the development process. And guess what, this approach doesn’t necessarily need a cloud environment, this is possible with an on-premises approach as well.

Legacy application will need to add the following extra steps:

• Codify the manual checklists that are used by operation for production deployment. These scripts will act as approval templates for developers to see how the new feature is doing in terms of approval readiness. (This might be introduced in test and pre-prod stages).
• Automate quality checkpoints to test and validate deployments. (This might be introduced as early as the dev-stage).
• Automate a consistent deployment across all stages (no human interaction e.g.: changing configs without migration process). This will help to gain confidence in the process, eliminate issues early, and will ensure hardening of the deployment pipelines.

Summary

Shift-Left is a process of moving quality assurance and deployments, as far away from production stage as possible. A Shift-Left mindset enables us to fail fast, build a blame-free error culture, produce higher quality products, and get a better understanding for the “Big-Picture”, without any negative impact on the team’s productivity or culture.