BazelCon 2024

Enticed by advanced features, several software teams have migrated their build systems to a modern generation of build technologies, such as Bazel. However, not all migrations lead to perceived improvements, ultimately culminating in abandonment of the build technology. In this talk, we will present the results of our recent empirical study of 542 open-source projects that adopt Bazel. We observed that (1) 61 projects (11.2%) have abandoned Bazel; and (2) abandonment tends to occur after investing in Bazel for a substantial amount of time (a median of 638 days). Thematic analysis reveals seven recurring reasons for abandonment, such as technical challenges, lack of platform integration, team coordination issues, and upstream trends. After abandoning Bazel, the studied projects have adopted a broad set of alternatives, spanning from language-specific tools like Go Build, to more traditional build technologies like CMake and even pure Make.

Discussing the last year of rules_swift, rules_apple, rules_xcodeproj, and rules_swift_package_manager updates, where we are going with the rulesets. Lots of time at the end will be open Q&A.

Bazel is typically described as a build system meant for large-scale systems. It's also described as a build system meant for teams with dedicated help to Bazel. But...what if you have neither? What if you are a small-scale start-up? Start-ups, by their nature, rarely have a spare headcount to devote to a build systems engineer. Their codebases are also usually pretty small. Why on Earth would you use Bazel in that context? Ergatta *is* using Bazel in that context. Ergatta has 1 MM LOC. Ergatta does not have the headcount to devote an engineer to Bazel. How does it work? How does a start-up with a 10-person engineering team work with a system that notoriously requires so much maintenance? In this talk, I'll talk about why we would ever entertain such a notion, what makes Bazel work for us, and how we remain productive in these times.

At Spotify, we migrated the Android Music app, consisting of 5 million lines of Kotlin, Java and C++ code, from Gradle to Bazel. This talk covers the how we did it, the challenges we faced and how we overcame them. We'll go into how we used a hybrid build to migrate the codebase iteratively, the various patches and performance improvements we made to Bazel and the features we implemented to release the app to end users.

Many at this conference are familiar with Remote Caching and Remote Execution. Over at BuildBuddy, we’re excited to introduce Remote Bazel - running the Bazel client server and command remotely as well, making your builds even faster and more correct. Even if your builds are triggered by ephemeral CI runners, Remote Bazel will guarantee your builds always run with a warm analysis and repository cache, and remove the need to pull images, install dependencies, and clone git repos on each run. Running builds in the same datacenter as the remote cache and executors also reduces network bottlenecks and egress costs. Even if your company’s developers use machines with different operating systems or versions of tools or don’t even have Bazel installed, Remote Bazel will guarantee that important builds are run in the exact same environment every time. This talk will provide a quick overview of how we built this and the many applications we’re excited about - from speeding up CI to augmenting our UI to improving the daily developer experience via the CLI.