4 ms·
Good heuristic for whether it's worth considering moving to bazel for your build system: - Do you have 200+ developers working on a monorepo? - Are you willin
by habitue 7y ago
Good heuristic for whether it's worth considering moving to bazel for your build system:
- Do you have 200+ developers working on a monorepo?
- Are you willing to vendor all of your dependencies and maintain their builds yourself?
If so, consider it. The productivity you're losing to unnecessary rebuilding and re-running unchanged unit tests will probably be paid back if you can contort your development process to the one Bazel expects.
If you're a small shop, the benefits Bazel is going to provide over, say, Make (or whatever standard build system your primary language uses), are going to be minimal. And the overhead of maintaining Bazel is going to cost you a ton of developer time you may not be able to afford.
- vlovich123 7y agoSo I always wonder how Google does this. Somehow they're able to determine which individual unit test are impacted by a change. Maybe this is only for Java but I'm pretty sure I recall claims that they can change 1 line & know that only 1 other test case is impacted (i.e. not even the other test cases within the same unit). Now Google's monorepo does imply also that if you are changing a line that is foundationally part of a lot of other components that they get rebuilt & retested too - that's the risk tolerance Google has chosen (i.e. they'd rather tests take longer if you're changing a core component rather than skipping tests & risking destabilizing 1000+ other engineers).
- habitue 7y agoIt depends on the granularity you write your BUILD files with. You can certainly write a target for each individual test, and track dependencies independently. In practice, you might glob together all files in a directory and put up with a few extra test runs in exchange for less bookkeeping
- vlovich123 7y agoWhat I was saying is that Google somehow manages to track test dependencies at the source level so globbing wouldn't matter.
- joshuamorton 7y agoFrankly you heard wrong. There isn't anything like this.
- vlovich123 7y agoYeah, I was misremembering the post from ~8 years ago. I was thinking of this https://testing.googleblog.com/2011/06/testing-at-speed-and-scale-of-google.html https://testing.googleblog.com/2011/06/testing-at-speed-and-... and it sounds like they do just use Blaze to keep track of explicitly expressed dependencies.
- IshKebab 7y agoI don't think you need 200 developers to make it worth considering.
- wereHamster 7y agoAnother factor: are your languages supported by bazel? If you use the same languages that google uses (C++, Python, go), it's fair to say that those are well supported. For all other languages, even if they are widely used outside of Google (JavaScript, nodejs), you may be out of luck.
- jefftk 7y agoI don't know much about bazel, but JavaScript is very widely used inside Google. It's the main language I work in.
- zapita 7y agoGo support is not great either. Bazel can build Go just fine, but you will need to throw away the standard Go tooling and use Bazel instead. There are third-party helpers like Gazelle, but you know you’re in for a bumpy ride when even basic operations require a helper.
- klodolph 7y agoGo support is awesome, IMO. Personally I have favored Bazel over “go build” for a while, except for pure Go projects with no generated sources. Gazelle is wonderful and it doesn’t belong in Bazel core. Bazel is a build system for every language, and Gazelle is for a subset of Go developers. Since it’s not part of Bazel core, you can always replace it with something else.