Quoting the Bazel website:
Bazel is an open-source build and test tool similar to Make, Maven, and Gradle. It uses a human-readable, high-level build language. Bazel supports projects in multiple languages and builds outputs for multiple platforms. Bazel supports large codebases across multiple repositories, and large numbers of users.
I started working on this project in 2016 as part of a role change within Google and my primary focus was to make Bazel run well on the macOS platform, specifically to support the Google-internal iOS development community. The port already existed when I joined the team, but it was mostly a prototype that lacked stability and polish.
What did I contribute?
Taken stright from my resume:
- As the Tech Lead of a subteam of 4, I provided direction, mentorship, and established planning and execution procedures to ensure we all saw the big picture and avoided team burnout. I also redid our planning process after observing routine pain points and gathering feedback from the team and from external TLs.
- Led a tactical response to the COVID-19 WFH situation to address pain points in builds on laptops with limited resources and on poor network connections.
- Rewrote Bazel’s dynamic scheduling feature, which is critical for good build performance, to make it resilient to networking blips and variable latency. See talk.
- Made Bazel on Mac able to reach Google-internal’s remote execution engine, which required porting the code to using gRPC, clearing roadblocks to establish a connection to production, and rolling out a new proxy service. This sped up clean builds by 50%.
- Wrote many public blog posts on Bazel internals and presented at various conferences (including the public BazelCon) to spread awareness about our product and our work.
- Sped up action sandboxing on macOS by 4x by designing and implementing a FUSE file system (sandboxfs) and integrating it into Bazel.
- Acted as the point of contact during an engagement with the YouTube iOS developers to address their pain points in developer velocity, and succeeded at fixing them.
- Added telemetry to our internal Bazel on Mac variant, creating a dashboard that has been used for years to understand the behavior of our user base.
- Established team-wide (~50 people) practices, like a bug triage policy and a weekly knowledge-sharing event.
Related blog posts
Addressing Bazel OOMs
Defining build time SLIs and SLOs
How does Google keep build times low?
How does Google avoid clean builds?
The final boss: Bazel's own JNI code
Bazel output streaming, Ctrl+C, and test flakiness
Bazel UI locking and file downloads
Shipping Bazel's new dynamic scheduler
Running codesign over SSH with a new key
Ensuring system rewrites are truly necessary
The OSXFUSE, hard links, and dladdr puzzle
Tree artifacts and transient files
Lifting the local lock for dynamic execution
Artifact downloads and dynamic execution
Output conflicts and dynamic execution
Bazel's dynamic strategy
How does Bazel track local resource usage?
Introduction to Bazel's dynamic execution
What are Bazel's strategies?
Waiting for process groups, macOS edition
Waiting for process groups, Linux edition
Waiting for process groups, introduction
Bazel's process-wrapper helper tool
A quick glance at macOS' sandbox-exec
Optimizing tree deletions in Bazel
Darwin's QoS service classes and performance
Using setenv equals setting global variables
Encode your assumptions
Hello, sandboxfs 0.1.0
Open files limit, macOS, and the JVM
A few extra system calls... and you lose 1% build time
Preliminary sandboxfs support in Bazel
Stick to your project's core language in your tests
A case for writing Bazel's integration tests in Java, part 2
A case for writing Bazel's integration tests in Java, part 1
Joining the Blaze team
On Bazel and Open Source