Following in the line of other organizations migrating their build pipelines to Bazel, Airbnb provided a detailed walk-through of the process that led them to leave Buck behind and improve both build times as well as project generation and loading times.
As Airbnb engineers Qing Yang and Andy Bartholomew explain, the decision to transition to Bazel was driven by the goal of offering a cohesive and efficient build experience across all platforms, including both the backend and the frontend.
Starting with their iOS development pipeline, Airbnb engineers focused on two main dimensions: build configuration and IDE integration.
Migrating the build configuration was somehow made simpler by the fact that Bazel and Buck share some similarities, including a comparable directory structure, similar command line invocation, and most significantly use the same configuration language, Starlark.
In spite of their similarities, though, Buck and Bazel differ in the set of rules they make available.
For instance, Buck offers rules such as apple_library and apple_binary, whereas Bazel, depending on the external rule sets, features rules like swift_library and apple_framework. Even in cases where the two systems have rules with the same name, such as genrule, the syntax for configuring those rules is often unalike.
The solution to this issue in Airbnb's case was creating a shim layer wrapping around the native and external rules. To handle both shims at the same time during the transition phase, Airbnb engineers created a repository with two distinct directories, rules_shim/buck and rules_shim/bazel, then defined a rule for each build system associating the rules_shim identifier to the right directory.
The rules_shim layer was also key to addressing genrule handling. Genrules are used at Airbnb to generate boilerplate in the iOS codebase and have distinct syntax on the two build systems. Thanks to the wrapper layer, Airbnb engineers could use the same genrule script across both systems.
The last area where build configuration required work was supporting conditional configuration. In this case, the mismatch between Bazel and Buck arises from the fact that while Buck provides a read_config function to read command line argument, which is not supported in Bazel. The solution was moving an abstraction layer downwards and reimplementing command line arguments through select, supported on both systems.
Coming to IDE integration, the goal of Airbnb engineers was replacing their existing Buck-centered solution to create Xcode projects with a Bazel-centered one without losing all of the tools they had developed around Buck. To this aim they decided to develop their own Xcode workspace generator using XcodeGen.
Most importantly, they carried out the migration process in three steps to avoid any disruption of developers' workflow. In the first step, the new generator was integrated with their existing Buck-based solution to ensure everything worked as expected. In a second phase, they added new Bazel commands that were equivalent to those used in Buck and made it possible switching from one to the other. Eventually, they removed support for Buck, once the new system seemed sufficiently stable.
The end result of this migration is impressive. Compared to the Buck-generated project (buck project), the generation time with XcodeGen has been reduced by 60%, and the open time for Xcode has decreased by more than 70%.
Besides that, the new Bazel-based build system reduced build times, especially for incremental builds and enabled further optimizations to improve sharing and collaboration. If you are interested in the full details, do not miss the original article.