Select Page

Bol’s journey in shifting left* and shifting right**: our Vision | Blog |

Published: May 22, 2024

*) in full isolation, relying on stubs and stub containers **) fully integrated pre-production environment ***) experiment with new cloud components, network or permission changes

In this post we’ll describe how that vision looks and why we believe in it, and in subsequent posts we’ll share more about its key elements.

The Vision

In 2021, many of our teams were still relying on a fully integrated pre-production (STG in further text) environment to validate their changes. They expected dependencies to be up and running, and production-like data to be present across the environment. They expected the chain to be available and reliable.

However, technological changes, data, privacy and access constraints imposed by always expanding regulations meant that guaranteeing a stable STG environment with consistent data across applications was no longer a reasonable expectation. It was time to change. Time to evolve.

We realised that the first key component of our future vision is TESTING IN ISOLATION for both functional and non-functional tests.We truly believe that by making a serious push for this shift left, teams will be able to deliver faster and with confidence.

However, this does not come without costs. Prerequisites for successful testing in isolation are:

  • Creating stubs is easy
  • Stubs are reliable.

This made us realise that we can’t have 170+ teams start writing their stub implementations for often as many as 10 dependencies their application relies on. It also became clear that the responsibility of providing reliable and trustworthy stubs should lie with the producers. We needed a way to have automation take over these manual and error prone steps while making sure the stubs are a trustworthy representation of an application.

Adopting an API-FIRST approach to development where APIs are considered first-class citizens rather than a technology to integrate sub-systems was an important step in realising this. API design-first enables teams to innovate faster by using CODE GENERATION to produce client/server code, mocks, and stubs. The quality of the generated code depends on the quality of the API, which is where API LINTING plays an important role. API linting will help the creation of high-quality APIs that can then be a solid base for code generation. This way the error prone manual work will be automated away allowing our engineers to focus on delivering value for our customers.

These three components represent the steps we’re taking to shift left.