Home
Welcome to the rules_ruby wiki!
We'll try to keep this well-documented so that those trying Ruby with Bazel have plenty of resource to address their issues.
But we start with some background.
You must have heard about mono-repos by now. It’s all the rage.
A Monorepo is when you put ALL of your enterprise code, regardless of the language, in a single meticulously organized single repository, and power it with a military-grade build system, and in some cases — military grade virtual filesystem.
Google is doing it, AirBnB is doing it, Twitter, Facebook, — the list goes on. But, does it really make sense to put all of your codebase in "one basket" so to speak? And even so, wouldn't that mean building this giant repo is a gargantuan task?
Yes and no. You see, over the last decade several highly successful internet companies adopted Ruby as the de-facto language for building enterprise components and services. Companies in this list include Github, AirBnB, Coinbase, SlideShare, Zendesk, SoundCloud, Groupon, Kickstarter, Scribd — the list goes on. As these companies became more and more successful, their technology stack became more and more diversified, complex, decoupled, and distributed.
It was during this hyper growth phase that many of the brightest minds in the industry (admittedly, starting with Google) came to the same conclusion that the architectural decoupling of software components, while highly desired as a software design concept, is not at all synonymous with a concept of a poly-repo — a practice of keeping small units of code, — think Ruby gems, — in separate repos. The way you manage your source control can either stand in a way of developer productivity, or serve as a tremendous accelerator.
It was then that Google had publicly pioneered the concept of a mono-repo, and slowly but surely it spread to some of the companies in our Ruby Giants list above. It turns out that keeping all source code together in what is now known as a mono-repo offers several unique benefits.
Oh, this is a fascinating topic. Without spending too much on this, I highly recommend you read both of those pieces:
- Monorepos: Please don’t! by Matt Klein from Lyft Engineering, and
- Monorepo: please do!
For one — with service meshes consisting of hundreds or even thousands of polyglot services, it becomes increasingly challenging to release new features that require changes across wide range of co-dependent poly-repos.
To properly review such a feature, an engineer must review several pull requests across multiple repositories, understand the cross-dependencies, catch any possible bugs that may arise from the new service boundary interactions.
Finally, the original engineer, having received all of the approvals on their pull request, must carefully orchestrate the deployment sequence as to not end up with the new code in production that’s relying on a yet-to-be deployed downstream service!
You can probably imagine that in this world no amount of safeguards, reviews, and canary deploy systems can help avoid issues altogether. And the folks that I spoke to, from those companies, pretty much said so.
Enter Bazel: one exceedingly powerful build system — Bazel, itself written in Java, Go and offering a scripting language called Starlark (a subset of Python) whose interpreter is written in Go. But why not? 🥇
Bazel comes with native support for C++, Go, Python, with support for NodeJS and Angular added later.
but Ruby support has been notably lacking. The author of this talk is currently involved in co-authoring Ruby Rules for Bazel build system, to allow Ruby applications and Gems to be built, run, and tested as part of the mono-repo. This is a new development in the Ruby world, and may pave the way for source code organization for years to come.
Come to this talk to learn about mono-repos, Bazel Build System, and the corresponding adventures of rubyists like yourselves — determined not to leave Ruby behind in this mad “Bazelification” of our enterprise source code. Notes to Conference Organizers If you take a look at https://github.com/bazelbuild — the Bazel github organization, you might notice that Ruby is barely mentioned, with the only link to Ruby Rules points to a personal hobby project from two years ago, who’s name is Yugui and she lives in Japan. We recently started collaborating and I am confident that by February 2020 we’ll something impressive to show. With a bit of luck on timing, the release of production-ready Ruby Rules for Bazel will be announced at RubyConf Australia 2020!
During this talk, folks at the conference will be able to download bazel, and “bazelify” their ruby apps in minutes. This will enable developers working on large codebases to consider whether or not mono-repo makes sense for them, and if the answer is “YES” they’ll be able to see the benefits of Bazel tooling, by seeing the incredibly fast and heavily cached builds and tests, and if time permits — parallelization and remote execution (see https://docs.bazel.build/versions/master/remote-execution-rules.html).
This is an audacious talk that will expose advanced and intermediate Ruby programmers to new ways of thinking about their Ruby apps — as cogs in a bigger software system, all orchestrated by the world-class, incredibly fast build system — Bazel.
Written by: Konstantin Gredeskoul