Bazel is an open-source build and test tool derived from Google's internal build tool Blaze. Bazel offers a human readable, high-level build language for describing projects. By leveraging dependency analysis and caching, Bazel is able to produce incremental builds in which only the affected resources are rebuilt or tested.

Peterson notes that as more and more tests were added within Dropbox's monorepo, running the entire test suite became too time consuming. By leveraging Bazel's dependency graph, Dropbox was able to "greatly reduce the number of tests executed on most commits while still being correct". This was coupled with rolling up commits into groupings on which the identified tests would be run.

InfoQ chatted with Peterson about his experiences in integrating Bazel at Dropbox.

InfoQ: You indicate that Dropbox server-side resides in a monorepo, what led to this decision?

Benjamin Peterson: We previously had more repositories, and we decided to move away from that for many reasons. Large-scale changes required manually submitting a code review to each affected repository affected. Sharing code was painful, so people tended to copy instead. Changes in one repository could break the tests of another. Each repository tended to develop its own "ecosystem" with a custom coding style, shared code, linters, and policies. We did a large repository consolidation 5 or 6 years ago. I'm sure the pain points I've described would be much more severe at our size today.

InfoQ: Some argue that the solution to tests taking too long to run within a large repo would be to split out the repo into polyrepos based on service/library boundaries, each running an independent CI pipeline. Was this an option explored at Dropbox before adopting Bazel?

Bazel is an open-source build and test tool derived from Google's internal build tool Blaze. Bazel offers a human readable, high-level build language for describing projects. By leveraging dependency analysis and caching, Bazel is able to produce incremental builds in which only the affected resources are rebuilt or tested.

Peterson notes that as more and more tests were added within Dropbox's monorepo, running the entire test suite became too time consuming. By leveraging Bazel's dependency graph, Dropbox was able to "greatly reduce the number of tests executed on most commits while still being correct". This was coupled with rolling up commits into groupings on which the identified tests would be run.

InfoQ chatted with Peterson about his experiences in integrating Bazel at Dropbox.

InfoQ: You indicate that Dropbox server-side resides in a monorepo, what led to this decision?

Benjamin Peterson: We previously had more repositories, and we decided to move away from that for many reasons. Large-scale changes required manually submitting a code review to each affected repository affected. Sharing code was painful, so people tended to copy instead. Changes in one repository could break the tests of another. Each repository tended to develop its own "ecosystem" with a custom coding style, shared code, linters, and policies. We did a large repository consolidation 5 or 6 years ago. I'm sure the pain points I've described would be much more severe at our size today.

InfoQ: Some argue that the solution to tests taking too long to run within a large repo would be to split out the repo into polyrepos based on service/library boundaries, each running an independent CI pipeline. Was this an option explored at Dropbox before adopting Bazel?