1–10 of 38 posts
Context: I'm ex-Google and I think blaze/bazel brings enough to the table to be worth the complexity even for startups, but wondering I'm underestimating the actual complexity.
I do not have notes handy so I don’t remember exactly what happened but my impressions after a week or two invested trying to get it running were a) that our projects had too many unsupported things (dependencies, flows) that would require a huge effort to adapt; and b) that it would take way too much effort for our small team to convert the 500+ repos we were building to release our software.
I have always dreamed of a time in which I’m able to fin a tool that fills this gap. Man, not having to build the same code that hasn’t changed over and over locally and in pipelines sounds so appealing.
We use Bazel at work and it’s sufficiently complex to write new rules. I’ve seen NX touted as a more approachable equivalent for smaller teams, maybe check it out?
I have tried twice in the past 5 years or so to convert different projects (mostly Java) to Bazel but failed miserably every single time. I do not have notes handy so I don’t remember exactly what happened but my impressions after a week or two invested trying to get it running were a) that our projects had too many unsupported things (dependencies, flows) that would require a huge effort to adapt; and b) that it wou…
I have tried twice in the past 5 years or so to convert different projects (mostly Java) to Bazel but failed miserably every single time. I do not have notes handy so I don’t remember exactly what happened but my impressions after a week or two invested trying to get it running were a) that our projects had too many unsupported things (dependencies, flows) that would require a huge effort to adapt; and b) that it wou…
Java seems like a particularly bad case to migrate for a non-google-size company, how does it even work? Do you have to check in every maven dependency to the monorepo as source?
Don’t be the Google hire that makes everything complicated. Be prepared to be told no, or to bring a better argument. We use Bazel at work and it’s sufficiently complex to write new rules. I’ve seen NX touted as a more approachable equivalent for smaller teams, maybe check it out?
Bazel only works if you have a dedicated bazel team to handle it. In general it's shit. Avoid, I hate bazel.
Bazel gets in the way of this use case. It will help your small team not break each other's builds. But you'll burn a salary on someone as the "Bazel person," they're going to write a bash script or make file for everyone else to use anyway, and when you inevitably rewrite everything from scratch the third time all their work is going to be for nothing and they'll spend days getting it back.
Just write a bash script or python script that does what you need for today, and plan to deal with it later. The only thing startups can afford is tech debt.
Another way of thinking about this is that your product is the software and not the software to build the software. Don't waste time thinking about the tools.
I've used pants at a small company <10 engineers and worked at a company migrating to Bazel with 200+ engineers. Bazel used to take a dedicated engineer 3-6+ months to bootstrap the full setup (creating the build files, seeing up the Bazel server, updating CI to use Bazel correctly including caching) especially since the docs weren't great from what I remember. I suspect that the time could be cut down by now especia…
A lot of the isolation and visibility control in bazel is totally useless outside of big companies.
https://earthly.dev/blog/bazel-build/
My thoughts, as someone who has done a lot of build engineering, but that has only a small amount of experience with bazel:
If you are working with languages that are well supported by existing, maintained bazel rules, maybe. Otherwise, the answer is likely "no". You do not want to take on the burden of maintaining significant rules, or figuring out how to mate your ecosystem of choice to an opinionated build system that nobody else in your ecosystem uses.
If you can manage with something easier to setup, it probably makes sense to do that instead. My general experience in startups is that you have to "pick your battles" constantly. You don't have the luxury of infinite time and resources. Work on the build system has a high opportunity cost.
Most developers and other people who aren't build nerds care about the answer to two questions in regard to builds:
1. Is the build fast enough?
2. Is the build working?
That's it. This is frustrating when they don't understand the other important aspects of build system quality, but it is also, admittedly, somewhat of a pragmatic perspective.
There is much leeway inherent in the speed question. If the build is slow, people can wait. Do they have any other choice? There is plenty of other work to do while they wait.
If the build doesn't work, you, THE build guy, are going to feel the pressure to get it working again quickly. This often turns to bodging, and eventually to something resembling life support. However, nobody will care how much of a brittle, knotted mess the build code is if it still manages to mostly work.
To put it bluntly: A startup company can probably survive with a shit build system. And that might even be the right answer depending on the context.
I would personally be perfectly happy to get paid to set up a beautiful, apex example of a build system for a startup, whether it makes business sense or not. My professional integrity just won't allow me to recommend that path unless I think it's justified.
I might recommend to start with a script, or a makefile, or a ninja generator, and see how that works out first. After all, that is how Google did it for a long time before they decided to create Blaze.