![]() Is it necessary to have a single WORKSPACE for the entire repo? Technically, no, but as soon as you divide a monorepo into multiple workspaces, you no longer have a true monorepo. This generally means everyone must agree on a collective set of dependencies and, more importantly, the versions of these dependencies. It imports the Bazel rules and external packages required by all projects in the monorepo. With Bazel, this is known as the “WORKSPACE” file. The larger challenge is managing a common set of third-party dependencies. Of course, picking up a new tool or framework is part and parcel of being a software engineer, so this shouldn’t be a major impediment. For starters, very few developers have experience with Bazel and must therefore learn it from scratch. Nothing is perfectĪlthough Bazel has many benefits and is a good match for monorepo-based development, it has its share of drawbacks. We are not yet taking advantage of remote execution, but it will become important to us in the future when we want to support larger and faster build jobs. The remote artifact cache is also available to our developers, meaning that each version of an artifact is built just once and then shared across developer workstations. With a remote cache we greatly improve build times on our continuous integration (CI) system, especially for C++ applications because they are built from sources down to the last transitive dependency, including third-party libraries. Remote caching is easy to set up, especially when using Google Cloud Storage. Bazel also includes a powerful query language that can analyze build dependencies, a capability that is extremely useful when creating a centralized build system for a monorepo (a topic we will cover in a future article in this series).īazel also has built-in support for remote artifact caching and remote build execution. It utilizes a common “workspace” that is typically shared among all projects in a monorepo. Unlike other build tools, notably Maven and Gradle, Bazel doesn’t rely on a wide-ranging ecosystem of plugins. In addition to being language-agnostic, Bazel is reliable, fast, scalable, and relatively easy to use. Hermetic means that builds shouldn’t rely on tools installed outside of the build environment, and build results are consistent regardless of the state of the system on which the builds are run. In fact, Bazel is completely extensible, enabling it to build just about anything that lends itself to a hermetic approach. It isn’t designed for a specific language in the way that Maven is mainly intended for Java, and CMake is well-suited for C/C++. One of the attractive qualities of Bazel is that it can build code written in a variety of languages. Bazel is the open-source version of Google’s in-house Blaze tool. When our monorepo was born, we chose Bazel as our primary build tool. ![]() Build tools orchestrate the downloading and/or compilation of source code dependencies, run automated tests, package various assets for deployment, and may perform other functions as well. From large applications to small microservices, the build process is often a lot more complicated than compiling some source files to produce a binary executable. These are essential tools for software developers. There are many to choose from such as Make, CMake, Maven, Gradle, and Grunt. But is it realistic to require everyone to use the same tool? And which one should it be?īy “build tool,” I’m referring to a build automation utility. Supporting fewer build tools means greater consistency and less complexity. If every project has its own build tool, it becomes more difficult to share libraries, create a common continuous integration (CI) pipeline, and switch between projects. One of the main reasons to develop software in a monorepo is for ease of reuse – not just source code reuse but also the community use of linters, code beautification tools, commit templates, editor configurations, and more. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |