Monorepo — the Google way to do CI/CD

Managing a huge codebase can be a daunting task, due to the need to keep in mind and constantly update multiple variables. Monorepo enables the true CI/CD, and here is how.

Source control done the Google way is simple. Instead of creating separate repositories for new projects, they create new top-level folders in their monorepo. This way they keep all the dependencies, variables and code components in one place. This is the reason behind their multiple daily product updates — every code commit essentially becomes a release once it passes the tests!

Let’s repeat this once more:

Every code commit essentially becomes a release with monorepo!

The implications are HUGE. Instead of pushing the code to Canary builds for user acceptance and letting it work for some time to fix the bugs, Google performs automated testing on the stage of committing new code batch to the repository. This allows saving an enormous amount of time and computing resources on testing. The best part — all the dependencies are updated automatically. This is… incredible.

Thus said, why not follow the lead and adopt the monorepo? If you implement this right, you are actually doing the truly Continuous Integration of new code (which leads to Continuous Delivery of new product features). Otherwise, you are doing frequent integration at best… The benefits for end users are also tremendous — they always use the latest stable build of your product and don’t have to rebuild or redeploy their environments. Everything just… works.

But there should be downsides, surely? Yes, there are a couple, and Google has kindly provided workarounds for these:

• First of all, many popular DevOps tools make unneeded assumptions that the repo is owned by the whole team. This results in a mess of the needed code reviews, bugs reporting, bug fixes and actions to be made after every change. The workaround is providing more granular code control, not only to show who owns the whole repo but to highlight which team member owns which code. The corresponding GitHub feature is called “code owners” and this helps define the workflow precisely, exactly the way Pull requests should work — collaborators ask the code owner for permission to update the code and check the change in the most convenient way.
• Secondly, issue trackers assume the repo equals the project. There is no simple solution, but the Angular team leverages user tags to organize the repo parts corresponding the various project parts. This helps ease and streamline the source control of the monorepo to make it a manageable and filterable codebase.
• Lastly, the numbers of notifications are overwhelming. When a team collaborates on a project, each team member gets lots and lots of GitHub notifications, which he should sift through to find the important stuff. When a huge organization works on a monorepo, the stream of notification turns into a flood. By now, the only solution is manually pinging the person responsible for the needed action, and this issue still needs solving.

As you can see, the downsides of using a monorepo are few and can be relatively easily overcome. They are surpassed by far by the savings in the resource expenses, product testing efficiency and software delivery pipeline simplification.

Final thoughts on using the monorepo to do the real CI/CD

We hope you will also appreciate the monorepo as much as we do. Of course, Jenkins and other CI/CD tools can work with multiple repos just as well as with a monorepo. However, the difference between frequent deployments and truly continuous integration is huge. When each new code commit seamlessly becomes the new product release, the testing is automated and done prior to building the code, you can totally omit the QA/Canary process and save a ton of resources, time and overhead.

The beginning of 2019 saw an interesting discussion on the benefits and shortcomings of monorepos and polyrepos between Matt Klein, the head engineer of Lyft and Adam Jacob, the CTO @ Chef. While Matt made his point that monorepos make code deployment at scale quite troublesome and demand dealing with multiple limitations, Adam replied in the sense that the main benefit of monorepos is increased visibility and responsibility across multiple teams in enterprize-scale environments. Multiple repositories make teams working at little code branches feel isolated and not responsible for the issues of other teams. Monorepo destroys such a situation from the get-go, as everybody is on the spotlight all the time, and the teams are forced to communicate and collaborate BEFORE major backward compatibility issues arise, not AFTER.

The benefits of using the monorepo for any business involved in software delivery are essential. IT Svit makes the most of this approach to code delivery pipeline management to power our projects, which results in multiple 5-star reviews of our satisfied customers on Clutch.co. Should you like to experience the same benefits — contact us and we will help your business succeed!