By Teodor Stefu on November 29, 2016
For our continuous delivery practice, an important part of shipping code to production is running automated tests against those production candidates to ensure the version of those applications work as we expect. Sometimes those automated tests take so long to run that it feels like it kills the flow of continually shipping. So, one of our goals this summer was to reduce testing time, even when the number of tests is high, so we can keep pushing code to production. By introducing Bazel to our Insights product we were able to reduce the testing time by 50% from 7 minutes to 3.5 minutes, and reduced our time-to-deploy by 70% from 9 minutes to 2.7 minutes.
BazelBazel is the open-sourced cousin of Google’s internal tool – Blaze. Bazel allows the automation of building and testing, developed by Google too. What makes Blaze unique is that it has been designed to solve build problems specific to Google’s development environment. According to Jeff Cox from Google’s Bazel team, it is suitable for projects that involve massive, shared code repositories, extensive testing and release processes and language and platform diversity.
It has proven to be both scalable and reliable after extensive usage by tens of thousands of engineers and tested over years on Google’s environment. It has proven to be build software quickly and correctly too. It’s speed is achieved by caching and parallel execution, as Bazel rebuilds only the files that are needed, instead of the entire project and runs tests only for the code that has been changed.
To understand Bazel and see if we could benefit from it, we first had to understand how it worked. Bazel works with WORKSPACES and each workspace is defined by a file named WORKSPACE (which can be empty). Inside every workspace you can define BUILD files with rules and each defined rule is a target. Each target will be a node in the dependency graph, and the target’s dependencies are edges.