4 ms·

We are a small 20ish dev company using a monorepo with mostly python. Our tooling is Bazel and Drone. - Ease of onboarding. Being able to quickly build or test

We are a small 20ish dev company using a monorepo with mostly python. Our tooling is Bazel and Drone. - Ease of onboarding. Being able to quickly build or test any target is awesome for the new employee. - Ease of collaboration. I can see all of the code easily and can learn from these patterns. I can also quickly contribute or extend apis and fix all usages without concern for breaking changes. Our use of Bazel quickly gets us around git scale issues by enabling external dependencies that can be loaded into the workspace without fully vendoring everything.

justinwp 8y ago
I would also say that while monorepos are not as necessary for the small, non-unicorn team, they improve the ability to get there by increasing transparency and preparing for a growth rate where the number of engineers doubles every year.
hknd 8y ago
That sounds cool. Could you elaborate on this "Our use of Bazel quickly gets us around git scale issues by enabling external dependencies that can be loaded into the workspace without fully vendoring everything."?
- oblio 8y ago
  The other question is: how stable is Bazel and how easy is it to extend and/or find open source extensions for it?
  - justinwp 8y ago
    We haven't had any issues regarding stability. For the most part we extend by creating additional rules. Many of these are supported by the community(search for bazel and rules_* and you should get a bunch of results on github).
- jsty 8y ago
  Not GP, but Bazel requires you to explicitly declare your dependencies for each 'target' you want to build. These dependencies can be within the same Bazel workspace, or imported at build time via say git - there's no need to have all the files directly in your repo. The nice thing is you can declare the commit id or file hash for the dependency you're importing to make sure you're getting what you expect, and keep Bazel's reproducibility properties. Source: one happy Bazel user :)
hu3 8y ago
I'm interested in using Bazel at work and would appreciate any input: 1) Was it hard to change projects and workflow to use Bazel (assuming the company didn't use Bazel at first)? 2) Is the dev workflow too different than typical git branch/commit/PR?
- justinwp 8y ago
  1) This is mostly dependent on language and the rules available. In our case python is a mess regarding 2/3 compatibility and external dependencies. There is a roadmap being executed on to fix these issues. Regarding our transition, it was slow at first as we pulled in services and tackled some tech debt. We wrote a handful of custom rules that helped. Bazel does have the ability to import repositories and that can be used as a little bit of a crutch in the process. 2. Exactly the same process except there is a single pr instead of multiple across multiple repositories. One of our challenges was integrating one of our public repos into our repo and that is more of a difference in release patterns(semantic versioning vs nightlies). We use copybara to help with this problem. - https://github.com/google/copybara https://github.com/google/copybara

justinwp 8y ago

I would also say that while monorepos are not as necessary for the small, non-unicorn team, they improve the ability to get there by increasing transparency and preparing for a growth rate where the number of engineers doubles every year.

hknd 8y ago

That sounds cool. Could you elaborate on this "Our use of Bazel quickly gets us around git scale issues by enabling external dependencies that can be loaded into the workspace without fully vendoring everything."?

oblio 8y ago
The other question is: how stable is Bazel and how easy is it to extend and/or find open source extensions for it?
- justinwp 8y ago
  We haven't had any issues regarding stability. For the most part we extend by creating additional rules. Many of these are supported by the community(search for bazel and rules_* and you should get a bunch of results on github).
jsty 8y ago
Not GP, but Bazel requires you to explicitly declare your dependencies for each 'target' you want to build. These dependencies can be within the same Bazel workspace, or imported at build time via say git - there's no need to have all the files directly in your repo. The nice thing is you can declare the commit id or file hash for the dependency you're importing to make sure you're getting what you expect, and keep Bazel's reproducibility properties. Source: one happy Bazel user :)

hu3 8y ago

I'm interested in using Bazel at work and would appreciate any input: 1) Was it hard to change projects and workflow to use Bazel (assuming the company didn't use Bazel at first)? 2) Is the dev workflow too different than typical git branch/commit/PR?

justinwp 8y ago
1) This is mostly dependent on language and the rules available. In our case python is a mess regarding 2/3 compatibility and external dependencies. There is a roadmap being executed on to fix these issues. Regarding our transition, it was slow at first as we pulled in services and tackled some tech debt. We wrote a handful of custom rules that helped. Bazel does have the ability to import repositories and that can be used as a little bit of a crutch in the process. 2. Exactly the same process except there is a single pr instead of multiple across multiple repositories. One of our challenges was integrating one of our public repos into our repo and that is more of a difference in release patterns(semantic versioning vs nightlies). We use copybara to help with this problem. - https://github.com/google/copybara https://github.com/google/copybara