Recently, I found myself mentioning the shift left approach quite often. Regardless of the fact that it’s a mega trend, dealing with release managers and their challenges, I think that the shift left approach is exactly what they need in order to improve their release management quality and speed. After all, what is release management if not providing early and quality releases?
Just a recap to those of us that are scratching their head right now: The shift left approach is all about doing things (mostly, but not just tests, as I’ll later explain) earlier in the development process in order to find defect as early in the process as possible, hance shifting them left.
For example, in the case of testing it means shifting the testing left, to be executed by the developer before committing its code, instead of running them later only on the continuous integration build. Doing this allows developers to test their code prior to committing it, fail faster (if they failed a test) and quickly fix their error instead of waiting for the CI/CD process to notify them on their failure. Besides failing faster and remain in-context, this approach also minimizes failed builds in the CI/CD, which results in a much more efficient and Agile dev process.
Yep, shift left also relates to “Agile” and other fancy words that people often mention but don’t always execute. Understanding something and knowing how to act upon it are two very different things. While most people out there can recite “shift left” and “Agile” in their sleep, when it comes to taking precautions and shifting left in order to become agile, they’re not there yet.
Just look at the 2020 State of Test Automation report – the report found that only 19% of companies surveyed rely on development teams for testing. And that’s without mentioning other areas, besides testing, they don’t realize they can shift left.
Let’s Start With the Obvious: The Shift Left Testing Approach
The shift left approach usually translates to earlier testing, all the way left to the dev team, rather than the Q.A team. And when I say usually, I mean almost always – until now, that is.
I would claim there is more to shift left in release management than just shift left testing. Don’t get me wrong, the shift left testing approach is great. When it comes to release management and the CI/CD pipeline, shift left testing is a life-saver. It basically means that you solve testing issues (integration testing, functional testing, and unit testing, for example) much earlier in the cycle. If you practice test-driven development and fix those issues early, or if you fail faster, you save a lot of time on coding, and you get to ‘stay in the zone’ of fixing the problem that otherwise would have been revealed only after the build fails in the CI/CD process. This, obviously, also saves a lot of the release manager’s time, as there are less broken builds due to failed tests. And the feedback loop is tighter, so you improve your quality (not to mention the smiles you will put on the QA team’s and the release manager’s faces).
The only problem is this process takes time, especially if build times are long. The code, build, test vicious cycle (if I may be dramatic) claims its victims in the form of frustrated developers that are waiting for the build to finish to test the product. Since the development team already has strict deadlines as it is, so many development teams choose to compromise on the shift left testing approach and test later rather than sooner. However, if your compilation time is fast and so is your testing process, then you really have what it takes to succeed in shift left testing.
So, you moved your testing to the development stage and made sure your testing and compilation times are fast to allow you to make your development deadlines? Now what? You get to take a breath and chill? Hardly. There is more to the shift left approach than just shift left testing. To thrive in release management, you cannot settle for just shift left testing, otherwise, you will be left behind.
Becoming truly Agile requires you to expand and shift left other areas that are usually located to the right of the release automation process, and including them in the release automation process.
Putting the “Sec” in DevOps: DevSecOps
Besides testing, there’s another field that is mentioned in relation to shift left (and generally): DevSecOps!
DevSecOps is buzzing. But it’s not just a buzzword: it’s part of this Agility I’m talking about. Just think, security vulnerabilities are exposed prior to the release, as they should. What was once to the right of the release automation, or the DevOps process (and often last in the cycle, right before deployment) is now, in many organizations, part of the release automation.
True, some consider security testing to be part of testing and therefore, part of shift left testing. But others see it as a new kind of Shift left, one that stands on its own two feet and highlights processes that were once to the RIGHT of the release automation process, and are now part of the release automation process (as opposed to shift left testing that shifts left from the release automation process to be part of the developer’s process). This shift translates to a lot of effort and a lot of money (saved), as this report by IBM shows: $80 on average to fix defects and vulnerabilities discovered early on, during development, as opposed to $7,600 to fix vulnerabilities discovered in production! That’s X95 more!!!
Image source: IBM
“Staging” Takes the Front Stage
Another example of a process shifting left to inside the release automation is an automatic staging environment. That means that you automatically check your production code prior to production as part of the release automation, instead of doing it at the end, manually.
Shift Left Inside Each Stage
There is another type of shift left: shift left in time. Instead of running processes such as code analysis over the weekend, for example, you can run them often, every day, or even per commit. This is made possible once you speed up those time-consuming processes. In the case of code analysis, it can be as much as shortening it from 36 hours (yes, that long) to 8 hours, allowing you to run code analysis processes every night. Reducing it even further will allow you to run it during the day, when the developers can fix issues found right away.
You’re shifting left the “when” rather than the stage these processes are at in the development cycle. You see, shift left is not just about shifting processes left from the release automation to the development team, or left from outside the release automation to the release automation; it’s also about running processes earlier in the development cycle and at a higher cadence, inside each stage.
Shifting Left Nightly Builds Towards a Build per Commit
Remember the build per commit I mentioned earlier? Well, shifting from nightly builds to build per commit is another example of shift left within the release automation. Just think of the implications of that kind of a shift. Instead of constantly compromising on when to run a build because it takes so much time to run it (even if it only takes a few minutes), you can speed up the compilation time and run it on every commit. Every Commit. It means you build changes earlier than ever before.
That’s a game-changer.
What makes it a game-changer is not the fact it offers speed, allows to avoid content switching, reveals errors earlier in the cycle, and provides fast feedback to the developer, but the fact that it points out exactly who broke the build. Trust me, for release managers, that is very significant. It means that they do not have to invest a lot of their time researching why the build broke and who is responsible. In addition, they can automate the build notifications to shoot a notification to the developer that broke the build. You can even take it further and create a gated check-in so that the ‘problematic’ commit won’t pollute the repository once the build fails. So, the repository stays ‘clean’ from problematic commits, allowing the release manager to always have a clean version at his/her disposal to release to customers or end-users.
Are You Doing Full Rebuilds as Often as You’d Like?
As a release manager, wouldn’t it be great if each developer could run full rebuilds, when they are most relevant, before they commit changes, treating them as if they were incremental builds?
Instead of compromising and running full rebuilds only in the CI/CD process, they would run earlier, in the development stage, and defects found in the full rebuild process will be found earlier and fixed immediately by the developer, rather than failing the CI/CD build. Again, to run full rebuilds so often, you’ll need to shorten your build time significantly, otherwise, it’s not feasible.
Don’t Compromise!
I’m sure we would all love to run tests by the developer, before code commit, but we compromise because it takes so much time. We would all love to run code analysis processes on a daily basis, but again, it takes too much time. You get the idea. Most of these “buts” are due to lengthy processes that are caused by a lack of computing power. A lot of you out there don’t even know you don’t have to compromise.
How Does Incredibuild Fit In?
I’m so delighted to be working in a company like Incredibuild because it is a significant enabler to the shift left approach, and therefore to the entire Agile methodology.
Shift left testing, shift left security, shift left nightly builds, shift left full rebuilds – you name it, we’re there! By turbocharging development and providing hundreds, and even thousands of available CPUs to each developer host and build server, Incredibuild dramatically reduces compilation, testing, and other processes time, allowing them to run frequently and earlier in the development cycle.
If you’re looking for a concrete example, just look at Retalix and how they shifted their testing left using Incredibuild, reducing unit test execution time from 2 hours to 12 minutes for every single developer.
Are you also having a ‘wow’ moment?
The shift left approach might be a relatively new trend, but we’ve been witnessing this shift for a while now. We’ve been shifting left tests and builds for our customers for two decades, and we won’t stop until we’ve shifted left everything we can.
