I don’t work there, but I have talked to Googlers working on build systems.
I'm trying to sell my team on it, but none of us has experience with bazel. I'm trying to figure out how to do a small poc where we migrate one intermediate thing in the monorepo to bazel and try to prove out how it can take over everything.
- You are going to screw things up a couple times. The documentation for Bazel is not always clear, but you can usually find examples or explanations of complicated stuff on forums somewhere.
- Start with a leaf dependency, something in your codebase that doesn’t depend on anything else. Then work your way up. Just write a WORKSPACE + BUILD.bazel in your root, and then put a BUILD.bazel in the directory for the dependency you are going to work on.
- Look at examples like Tensor Flow, especially for how to handle third-party dependencies (although Tensor Flow is going to do it in a more complicated way).
- Migrate your tests as you go.
- Just run "bazel build //...:all" or "bazel test //...:all" from your project root as you go to make sure things don’t break.
- Undoubtedly it will take a while to develop a good mental model of how Bazel works. For fun, try looking around in the output directories, or look at the sandboxes it creates.
What if I wanted to fork tensorflow and integrate my project into it, would I need the tensorflow fork as something like a git submodule in my main repo, or is there a way to tell bazel there's another repo somewhere else and where it fits into the graph?