Shortly after posting Narrowing the Imagination Gap with the Test Pyramid in Action, Pepper Lebeck-Jobe put me in touch with Helen Altshuler. As a result of that generous connection, I’ve been working for EngFlow, a 100% remote startup, since March 4, 2024.
This past Thursday, June 27, I published my first EngFlow blog post, Migrating to Bazel Modules (a.k.a. Bzlmod) - The Easy Parts.1 It’s the first of a series I’m writing on Bzlmod migration challenges and solutions.
As always, feel free to chime in on the LinkedIn announcement corresponding to this post.
About EngFlow
Yet again, I have my blog and the kindness of others to thank for pointing me in an exciting new direction. Well, sort of new…
EngFlow was founded by a few ex-Googlers to provide fast and massively scalable remote build, remote test execution, and results reporting infrastructure. Many of them worked on similar infrastructure within Google, and remain active Bazel contributors and Bazel community leaders.
Those who know my history—even the history I haven’t written about yet—already know how much sense this makes. For those who don’t, here’s the short version from a bio I wrote this past week:
As leader of the Testing Grouplet, Mike helped launch Blaze, SrcFS, and Forge (remote caching and execution) at Google during the Revolution Fixit in 2008. Now he’s having déjà vu all over again at EngFlow. He lives in northern Virginia, and wishes he was playing electric guitar right now.
What is it, I would say, I do here?
Well, that’s been the the big question throughout my career. I’m a programmer, but I’ve ended up essentially (and largely accidentally) making a career out of glue work.2
I’m still sorting out a distinct groove at EngFlow,3 but I’m gravitating towards providing documentation and training to help overcome build and test challenges. Specifically, challenges that could hold customers back from getting the most value from our platform, or even being able to use it at all. As it was with Google’s code in 2008, the remote environment imposes constraints that require a degree of discipline beyond what a local environment allows.
In fact, I’ve already revamped the landing page of docs.engflow.com and the EngFlow overview page to make them more accessible. I’ve also added the Build the example project page as an exercise for trying EngFlow (with Bazel) without having to set up your own project.
Still, I can’t help getting my hands somewhat dirty with code of some kind…
Taking the Bzlmod bait
While I was writing the Build the example project exercise, I had a problem
building one of the packages in the EngFlow/example repo. The most
straightforward fix appeared to be to migrate that repo from WORKSPACE to
MODULE.bazel, the configuration file for the Bazel modules (a.k.a.
Bzlmod) mechanism.
Before I left Google in 2011, Blaze had no concept of external dependencies or a
WORKSPACE file. Everything required to build the code in the Google monorepo
environment, targeting the Google runtime environment, was baked into the tool.
In the intervening years, Google open sourced Blaze as Bazel, and I barely used
it except in some small QCI Training projects at Apple.4 So
when I joined EngFlow, I effectively had no experience with either WORKSPACE
or MODULE.bazel.
In the process of migrating the EngFlow/example repo, I got the bug to learn
more about Bzlmod. Our main internal repos were still using WORKSPACE, so I
asked if anyone would mind my attempting to migrate them. It would be a way for
me to contribute some important, but not (yet) urgent technical work, and
potentially solve problems our customers might face. I’d get to know our
codebase better, and engage with more of the team in the process. Folks were
supportive, so I took the opportunity and went for it.
To say things got (technically) interesting would be an understatement.
Migrating to Bzlmod and living to tell about it
I did a lot of research while solving one problem after another, and couldn’t have finished the project without the generous wisdom of existing materials. My EngFlow colleagues, some of the foremost Bazel experts in the world, were a huge help throughout. However, many of the existing migration guides and examples were for smaller projects. I learned a lot from them, but I didn’t find any comprehensive guides for large, complex migrations like the one I’d undertaken. Plus, some of the Bzlmod behaviors and solutions I discovered were surprising even to my Bazel expert colleagues. I even filed a legit Bzlmod bug.
Once I finished the project, I believed that it would be useful to share what I
learned with the broader community. I wanted to provide a useful reference that
tied a lot of these experiences, resources, insights, and tactics together. I
also figured it might help some of our customers overcome friction and avoid
remaining stuck on Bazel 8 after Bazel 9 removes WORKSPACE altogether.
Hence my first EngFlow blog post, mentioned above. Solving all the little
problems that came up during the migration was a lot of fun, and so was writing
about them. If you’re not working with a large codebase staring a bunch of
complex WORKSPACE dependencies in the face, it may not be for you. But if you
are, I’d love to hear what you think, and if you found any of it helpful.
Footnotes
-
I actually did a heavy edit of an earlier post, Bazel scales more than just builds. I kept almost all the original text, but reorganized it and added section headings. But there is one original paragraph that I contributed, starting with "The result of these issues…". ↩
-
I really like this definition of so-called "glue work," but I hate the advice to not do it. I mean, I do get that it’s historically fallen disproportionately on women, and I agree that the senior technical leadership should do more of it. But I’m more of the mind that it’s better to encourage making important work visible than to recommend that anyone avoid doing it. It’s not a problem with an easy solution, but so few important problems have one. I’d like to see the software industry do better on this issue than continue to succumb to the prisoner’s dilemma. ↩
-
One recent observation I’ve shared with the team: This is the first company where I haven’t had to persuade people to improve their testing practices. After all, many of them spent years at Google after I’d left, after test sizes and TotT and Test Certified were baked into the culture. We talk about code quality regularly, and everyone takes code coverage and fixing flaky tests seriously. No one needed me to say anything before they started working on that stuff. So one thing I’m so used to doing is right off the table. ↩
-
I was inspired to do this by Simon Stewart’s work driving Bazel adoption. ↩