BlueLabs designs and implements platforms for the sports-betting industry from the ground up. The company is currently developing an end-to-end solution, collecting the sports data and events, accepting and validating bets, handling results and payouts, and delivering the best UX possible with the web platform.
The Challenge
The frontend team started experimenting with a monorepo. They were suffering broken releases due to incompatible versions in their own ecosystem. Wanting to release as much code as possible and being experienced at publishing Node packages in private repositories, they decided to give monorepos a try.
The first thing the team realized was that the build process in a monorepo is slower. This was noticeable because they were the only ones at the company with a monorepo, and it was standing out in the overview. So, they had to allocate some time to optimize the pipelines, mostly via caching dependencies and artifacts, and using Docker more efficiently.
Overall, BlueLabs needed their new CI/CD solution to
- Understand what has changed in a monorepo
- Keep their build times under control
- Have an immediate strategy for storing artifacts
- Establish a short feedback loop on changed code
The Solution
BlueLabs monorepo has two main folders: apps for brand-specific applications and packages for shared code. Their Aha! moment came when they realized that running static analysis and tests alone in one package took longer than building all the packages at once. That’s where they decided to go for a different approach: make tests selective and keep builds atomic.
This realization, coupled with the introduction of a CI that tests only the code that changes, allowed them to reduce build times by x4. Below you can see a screenshot of the latest run, where only a small UI change in one of the packages was committed. The entire codebase is built to deliver the application, but tests and static analysis run only where the updates were made.
The secret sauce was the adoption of a new change_in function, which calculates changes in recent commits. With it, setting up conditional execution in a monorepo is just a matter of adding a single line of code in the pipeline.
The Results
The improved pipeline let BlueLabs establish a short feedback loop in their development cycle. The parts that changed are more readily visible, the whole build process is faster, and developers need not wait until their coffee gets cold to know if tests have passed. Not only developer productivity has improved, but BlueLabs was able to reduce costs in their CI/CD.
Once developers got more experienced with monorepos, they were able to set more specific change conditions and use artifact caching better. Today, the codebase has grown by 30% since they switched to monorepo, and the average duration of their longest pipeline went down four-fold, from 17 to just 4 minutes.
