Operating Your CI/CD Process Like A Formula 1 Team

I was chatting to a friend the other day about how much time racing drivers spend in the "pit lane", their "speed on the track" and "collisions on the track" in a Formula 1 race, and how all of these factors determine success or failure in each event.

He also happens to be a software developer, and has led dev/ops teams in number of software companies, and he used the Formula 1 example to draw an analogy with some of the challenges he has faced in his career and how this led to the creation of a new company.

Three of his ongoing battles were (1) how to minimise the time in the "pit lane", by reducing the time spent diagnosing why software releases were failing (2) increasing the "speed on the track", by minimising the elapsed time of every testing run (3) "avoiding collisions on the track", by preventing bad code going into production.

In today's world every organisation that is looking to the future has some form of Digital Transformation taking place. The business impact of delays in the software release process, as well as code failures in production releases, can have a profound impact on a companies reputation in the market, customer retention, new revenue streams and bottom line.

In the places where my friend worked they used CI/CD platforms, releasing daily or every few days, but new releases could occur multiple times a day if needed. This was often accelerated further by business executives and product managers who would demand one-off changes, potentially just on a whim.

With such frequent code changes, it would be tough to track down the issues that caused testing failures, which could be the result of bugs in the codebase or failures in the actual tests themselves = time in "pit lane" to identify where and why things had failed.

Delays in releases could also be caused by slow tests or a sledge hammer effect where the test coverage was broader than was required, versus only focusing on the things that had changed in the codebase = slower "speed on the track" because testing was not optimised for each release.

It was also not uncommon for untested code to end up in production because the test coverage for changes in code was not clearly understood prior to release = more "collisions on the track" and time in the "pit lane", with a heightened degree of stress and pressure from the business in these scenarios, because of the business impact.

All of this was further complicated by the fact that dependant pieces of code were distributed, across their own data centers and in the cloud making the process of diagnosing failures even harder.

Sound familiar?

The Genesis Of A New Company

Based on his real world experiences, an acknowledgement that these challenges are universal in nature, from small to large organisations, an understanding of the impact they have on development costs, and knowledge of the business impact of delayed releases & production downtime, he decided that the time was right to build a new company to tackle the problem head on.

There were already software companies out there offering observability tools to monitor metrics in CI/CD platforms but these still required a lot of interpretation by skilled personnel to be of any use. What was missing from all of these solutions was the "intelligent analytics" required to provide "actionable insights" to solve the challenges he encountered in a holistic way.

What came out of this was a new product called Foresight.

Foresight For Your CI/CD Pipelines

With Foresight you can operate the CI/CD process like a Formula 1 team, by minimising time in the "pit lane", avoiding "collisions on the track" and maximising "speed on the track" throughout the process from testing to production by;

1. Dramatically reducing the mean time to identify the cause of failures in the testing process.
2. Ensuring that only high quality code finds its way into production, through automated risk assessments that are based on test coverage of changes in the codebase. Leveraging this releases can automatically be approved or reviewed with all of the relevant data to hand, prior to approval.
3. Dramatically reducing test cycle times by automatically selecting and running the tests that need to be run, for the changes that are introduced to the codebase and those that are most likely to fail.

Today Foresight is available for Github Action Workflows (CI/CD pipelines) and can scale from small to large development teams. You can find some great resource to learn more about the company and product here.