Yes, it's complicated, but it's also quite rigorous, and the rigor pays off.
(We at Square had already found a Blaze-alike necessary. We are currently busy converting our Java build from Pants to Bazel.)
Everything is hard, unfortunately.
Doing that in one repo makes the commit part easier, but hides the complexity of deploying separately. Or to other places.
Not that two repos makes it easy. Just gives a much earlier signal to where it happens.
In my experience, you're required to break changes up into safe individual deployments anyways, so the monorepo doesn't add any benefit in that sense.
You will soon experience:
- dependencies hell due to transitive and conflicting dependencies
- one back-incompatible change in some obscure library end up breaking some other unknown service that happens to transitively depend and it
- the entire codebase will become a mess due to inconsistent code styles and formatting because hey we are developers and we can never agree on anything. Thus each team lead will have its own opinion
- each team will have to maintain its own CI/CD jobs
- heterogeneous builds: maven, node, sbt, webpack, etc ...
the list goes on ...
All (or most of) this mess is solved by centralizing the codebase in a monorepo.
Both approaches take a huge amount of work and tooling.
The big selling point of a monorepo is that the time and effort taken to follow strict versioning and upgrade discipline for multiple interdependent projects can be somewhat avoided. On the code side.
Essentially: version skew across numerous artifacts in a large organization starts to look like the version skew across an industry or ecosystem. The aggregate cost of dealing with it project by project is probably higher, at least that is what most of the biggest tech companies have concluded, than dealing with it at the source level using a monorepo and single-version policy.
EDIT: Looks like I've misread the parent's argument as one against monorepo. It was in fact an argument in favor, and one I agree with.
Having looked seriously at both options, I think the monorepo world is the right one, but it presently lacks good tooling to sanely model your dependency graph AND create custom build rules while still being affordable for small or medium-sized orgs. Git/hub simply isn’t designed for this kind of modeling and everything I’ve seen built atop it is either way too manual or a kludge. Maybe the “kludge” solutions are actually reasonable, but my confidence is low.
Bazel is the right idea, but it’s execution disappoints. The documentation is abysmal, last I checked they advertised Python 3 support, but it’s been broken for years with no signs of progress. Building custom rules also looked hopelessly complex (by which I mean, “not something our organization can afford to implement and maintain”) but maybe there’s some undocumented happy path that I’m missing out on? These things seem easy enough to implement. We’re using Pants right now, and for it’s many similar problems (bugs, documentation, poor code base, difficult extensibility), it at least does a passable job at building Python projects.
I’ve thought about it a fair amount, and I think it’s reasonable to build something simpler that might not meet Google’s use case, but would at least enable small and medium sized shops to play the monorepo game.
The next obvious question is, what would you do to make it simpler? Tons of people have tried (you listed 5), and they all rebuilt the same thing. What features do you drop?
I understand that "it should be simpler" is a pretty lazy criticism. It's been a while since I audited Bazel and friends, and I've forgotten which issues apply to which tool. Moreover, because of the awful state of the documentation and the messiness of the code base (or perhaps this is just standard quality for Java projects?), it's really difficult to tell whether any given issue is actually a fundamental shortcoming in the application or whether it's simply a knowledge gap.
As far as what I want, keep the starlark configuration file format; implement all rules as starlark libraries (such that no one needs to write Java to extend, and if you must write Java then for goodness' sake fix the plugin interface or document it better or something such that one doesn't need to be a core contributor to implement a plugin--perhaps this is fine for an enterprise audience, but it's not fine for my use case). The rules should call into a base `mktarget()` or similar that takes args like the target's ID (the package:target_name pair), a target type that identifies the code used to build the target, and a dict of args/params that are passed into the aforementioned code. The args/params can be an arbitrarily nested JSON-like type so long as the leaves are primitives (int, string, etc), references to source files, or other targets and all leaves (and transitively, the whole structure) must be hashable such that we can identify a given execution of the build.
Beyond that core operating model, the code and the user interface should be clean and well documented. Ideally, small and medium-sized projects shouldn't need to run it in daemon mode to get reasonable performance. This is important because a daemon running on local development machines introduces a larger maintenance burden (there's just more that can go wrong). Language-specific plugins (custom rules, whatever you want to call them) should adhere pretty closely to the conventions of the target language. Lastly, there should be good support for building toplevel artifacts--this means I should be able to build a whole CloudFormation package including lambdas, Docker images, etc just like I would build a JAR or a C++ binary.
I realize that those things are easy enough to say, but the devil is in the details. I've actually gone so far as to prototype the implementation, so I'm confident that those goals are achievable. Unfortunately, it's a pretty significant effort (mostly due to the breadth of project types/languages to support and the nuance/expertise required to support any of them), so I'm bound by free time. If anyone is interested in collaborating or discussing more in-depth, hit me up on Twitter @weberc2 or email me (username at gmail.com).
we don't use bazel (yet), because dotnet is not that supported.
Bazel goes through great pains to only rebuild the minimum necessary for correctness. It's able to do that because bazel build files get a lot more information about the source level dependencies than a Nix file does
Using Bazel with external packages on the other hand is one of the most tedious and frustrating endeavors imaginable. If you can vendor all of your source it's much less frustrating. This is extremely manageable in the C and C++ worlds where there aren't really any package mangers and you end up needing to do that anyway.
Edit: I don't want to come off as too negative about Bazel. But I really think it needs more time and is nowhere near something that I would call a 1.0 let alone a 2.0
I’ve been using it for the last 2 years, and I am not doing any project again without it.
Bazel is not that complex if you start a project with it. Migrating to it and learning it at the same time will be hard though since you’re likely to uncover a lot of skeletons.
Bazel is quite complex and when you start a project you do not yet need it, rarely will an organization start with something like Bazel, they use it because - you hope - they need it.
vs:
> Migrating to it and learning it at the same time will be hard though since you’re likely to uncover a lot of skeletons.
So the bulk of Bazel use cases will revolve around migrating an existing build system to use Bazel instead, and that is hard, because Bazel is difficult and has a very steep learning curve, and requires a lot of work to keep it running.
Tooling should adapt to use cases, if you need to adapt your use cases to the tooling then that's a fault of the tool. If that limits use of the tool to those projects that are started with it then you have already lost the vast majority of your potential audience. So yes, if you start using Bazel right from day #1 then that might be the way to go. But I suspect - and so far have not seen any evidence - that that is the way it is actually used.
Bazel is hard in the same way Rust is hard. If you port your existing project to it, chances are you will run into issues because you were doing things wrong with respect to hermeticity or reproducibility. It goes really far to make things correct. You may not need it, but when you do it’s a godsend. Or at least it was for a lot of people I talked to. And my own experience as well.
If your project is vanilla enough, things will go mostly smoothly and the benefit will be immediate (ie bazel clean is a legend).
Think of Bazel as a framework. If you do thing its way, it will spoil up. But sometimes a framework is not what you need. That said, if you’re happy with your current system, then good for you!
This is not only related to the size of the company but rather the size of the project. For instance if the project requires polyglot build or codegen (gRPC does both for instance), Bazel will shine and save a lot of time and headaches.
That’s not to say that it’s without its problems and that some use cases are very rough around the edges. Which is something the team and community are working to fix.
For very large organizations with the capability of assigning one or more teams to tooling it may very well be the right choice.
But which one? Are there any other (non blaze-like) build systems enabling hermetic (possibly remote) builds and caching?
If you don't need these properties and have a mono language project, the language's native build system sure fits and may be a better choice.
You can of course try to use the native solution on each but that makes it more difficult for people to jump between projects/languages as the syntax for describing the build changes. Moreover for centralized build infra this becomes more difficult to orchestrate/co-ordinate because now you have to add remote caching/parallel compilation & whatnot to multiple places (with all the associated challenges of trying to upstream the same set of logical changes into many different projects with their own maintenance schedules/philosophies).
If you have a small project that you can rebuild in a couple of minutes, Bazel is probably an overkill.
I feel like I see the pattern of people on HN being disappointed in some of the tools that come out of Google and other large engineering orgs, when they don't work out really well in orgs that are not operating at the same scale. People have similar complaints about the complexity of other projects that come out of Google. K8s comes to mind as one such example. Often times these tools must be robust to such a large variety of uses that they are simply overkill for smaller organizations. I'll readily admit that I could be wrong and Bazel is simply poorly designed, but it is perhaps worth considering that the build system used by an engineering team of 50 need not be as complex as the build system used by one of the largest engineering orgs in the world. My guess is we'd see a lot less backlash if people tried to step off the hype train for a moment and critically evaluate whether they really need to use something like Bazel or K8s when something simpler would suffice.
This kind of cargo-cult process copying has infested the start-up world and is akin to sending a lot of shirts to the laundromat because that's what rich people do and you want to be rich too.
These things work for large companies because they are large companies. Their problems and associated solutions rarely if ever are a good match for the kind of issues that your average start-up contends with, especially early on in the life cycle.
You and your buddy the first-hire developers are not going to gain anything by copying the Spotify development model, and other examples in that vein.
> Build and test software of any size, quickly and reliably
Given the comments here, a tagline focusing on its strengths for large orgs/projects probably would be better marketing.
I don't blame the bazel authors, but the development process it was designed for is not the development process of 99% of companies out there. Maintaining BUILD files for all of your vendored dependencies is expensive for your company. You need a full time team working on it.
Unless hermeticity and build correctness issues are absolutely killing your team's productivity (and at a certain size, they might be!) think twice before adding bazel to your maintenance overheads. You can always move to it later if you need it, and it might be more stable and have a better 3rd party package story by then