Ultimate Monorepo and Bazel for Building Apps at Scale: Level Up Your Large-Scale Application Development with Monorepo and Bazel for Enhanced Productivity, Scalability, and Integration (English Edition)

CHAPTER 1

Introduction

Introduction

In this chapter, we will delve into the world of Monorepos and their significance in modern software development. We will start by gaining a comprehensive understanding of the Monorepo approach and how it ushers in a true era of continuous integration, breaking down the traditional silos that have plagued Polyrepo structures. We will explore the drawbacks of Polyrepo systems and contrast them with the numerous benefits that a Monorepo can offer. To appreciate the roots of Monorepos, we will take a brief journey through their historical evolution. Along the way, we will address common fears and challenges associated with implementing a Monorepo and discuss the transformative power of Bazel in Monorepo development. Delving into the history, features, and design logic of Bazel, we will help you grasp why it is such a valuable tool in this context. To guide your decision-making process, we will also discuss when to opt for a Monorepo and when it might not be the right fit, as well as when to choose Bazel and when it might not be the best choice. Lastly, we will provide a list of recommended readings to further enrich your knowledge in this exciting realm of software development.

Structure

In this chapter, the following topics will be covered:

Understanding the Monorepo Approach

The Power of Bazel in Monorepo Development

When to Use Monorepo and When Not to Use it

Bazel Features

Understanding the Monorepo Approach

A monorepository, often referred to as a Monorepo, is an approach to software development that involves managing distinct "code parts" with well-defined relationships within a single repository. These code parts can vary in granularity, from entire applications to intermediate-sized functional units such as business operations, or even individual architectural components.

While these sections may have dependencies, they typically maintain logical autonomy and are overseen by different teams. Each has clear dependencies on others, as well as on external libraries, resources, and similar elements.

Figure 1.1: Application projects and its dependencies with common shared projects

Monorepos are not a silver bullet; there is no universal solution in software development. Yet, by the end of this book, you should understand the potential benefits of a monorepo, the challenges you might face, and whether it aligns with your organization’s needs.

In a monorepo setup, multiple projects are housed within one repository. These projects can depend on each other, enabling code sharing. When you make changes, there is no need to rebuild or retest every project in the monorepo. Instead, focus on rebuilding and retesting only the projects directly affected by your changes. This approach is often called "incremental builds".

Figure 1.2: Teams maintain one or more interdependent projects

Incremental builds grant teams within the monorepo a degree of independence. If two projects do not depend on each other, they remain shielded from one another’s impacts. One team can advance with development, testing, PR merges into the main branch, and other related activities without having to run code from the second team. While the second team might face challenges like unstable tests, poorly typed code, or broken code and tests, these issues will not disrupt the first team’s progress.

Welcome to the True Continuous Integration

A Polyrepo embodies the traditional approach to application development: each team, application, or project maintains its own repository. Generally, each repository yields one build artifact and adheres to a linear build pipeline. Polyrepo configurations often depend on previously published artifacts. Ideally, every repository integrates continuously (CI) with the latest version of its dependencies, facilitating smooth integration.

Figure 1.3: At a Polyrepo, components are shared through published artifacts

In a Monorepo, all code changes (commits) belonging to the same code contribution (a complete and accepted feature) is viewed as a pull request, or a merge request in case of using the GIT version control system. These requests must synchronize with the most recent commit in the main branch, but there are similar concepts in other tools. This synchronization ensures that all internal dependencies match the current source code version, and external dependencies align with the newest globally defined version. This rigorous procedure ensures that code contributions integrate fully with the latest changes in the main branch.

Drawbacks of Polyrepo

The Polyrepo approach has gained traction in the industry largely because of a pivotal factor: team autonomy. Teams desire the liberty to choose their libraries, decide the timing of app or library deployments, and determine who can contribute to or use their code.

However, the challenge with Polyrepos is that autonomy often stems from isolation, which can impede collaboration. In contrast, a monorepo achieves autonomy by endorsing detailed project management, supporting incremental builds (as discussed earlier), and implementing pull-request continuous integration with both manual and automated approvals. These approvals might include tools like CODEOWNERS files, which assign specific individuals or groups as the custodians of the code in a repository. These custodians are involved during code contributions, especially when changes affect their projects.

In Polyrepo configurations, shared code typically requires a separate repository. Setting this up means configuring the necessary tools, establishing a CI environment, adding authorized contributors to the repository, and creating mechanisms for package publishing to allow dependencies from other repositories. Additionally, harmonizing conflicting versions of third-party libraries across repositories can be challenging.

Setting up a shared repository within a Polyrepo can be time-intensive. As a result, many teams might decide to create their own versions of common services and components within their respective repositories. While this might be expedient initially, it escalates the effort needed for maintenance, security, and quality control over time as these elements evolve.

Once a shared repository is operational, initiating cross-repository changes to shared libraries becomes an arduous task. Developers have to adjust their environments to enact these alterations across various repositories, each with its unique revision history. This requires significant coordination concerning versioning and package releases.

In a Polyrepo setting, teams often use their unique command sets for tasks such as testing, building, serving, linting, deploying, and more. This inconsistency adds cognitive load, as team members must recall the appropriate commands for different projects.

Benefits of Monorepo

Initiating new projects is streamlined to creating a folder paired with a project descriptor. These projects readily tap into the existing CI setup, negating the need to release versioned packages when all users are housed in the same repository.

In this cohesive setup, every component interacts seamlessly with each commit. As a result, modifications across various projects converge into a single atomic commit—changes are either fully implemented or not at all. This methodology dispels the notion of breaking changes as any concerns are addressed within the same commit.

Compatibility concerns stemming from projects using clashing versions of third-party libraries are eliminated. All such dependencies are precisely cataloged in a centralized, shared third-party dependency definition file. The threat of a library becoming obsolete due to team unavailability is reduced. Any team can modify a library version (subject to certain automated checks), and the CI system guarantees that all projects stay operational by running extensive unit tests—a safeguard ensured by unit testing.

Moreover, a monorepo fosters developer flexibility among teams. It instills a uniform approach to building and testing applications, even when they are developed using varied tools and technologies. Developers can contribute to projects overseen by different teams, ensuring their changes’ safety and compatibility.

A Bit of History

In version control systems’ early days, like CVS (Concurrent Versions System) and SVN (Subversion), separate repositories for individual software projects or components were the norm. This methodology was apt when software initiatives were largely compact and independent.

The rise of distributed version control systems, notably Git, in the mid-2000s, ushered in greater flexibility for developers. Git’s decentralized architecture empowered them to operate across multiple branches and repositories, simplifying collaboration on expansive codebases.

Google often receives credit for advancing the monorepo paradigm. Internally, they adopted an extensive monorepo around 2008, encompassing nearly all their software projects’ source code. This approach afforded Google more streamlined management of its vast codebase through an internal tool named Piper. The efficiencies, such as enhanced code sharing, unified dependency management, and standardized tooling, spotlighted by Google’s Monorepo, sparked intrigue in the wider developer community.

Subsequently, tech behemoths like Facebook, Twitter, and Microsoft embraced Monorepos. They discerned the perks of a consolidated repository to oversee their extensive codebases that spanned varied languages and platforms. To make Monorepos more palatable for entities beyond these giants, a slew of open-source tools and frameworks emerged. These include Gradle Build Tool (by Gradle, Inc), Lage (by Microsoft), Lerna, Nx (by Nrwl), Pants (courtesy of the Pants Build community), Rush (by Microsoft), and Turborepo (by Vercel).

The Monorepo methodology has steadily carved a niche within the developer community. Numerous entities, from start-ups to conglomerates, have transitioned to Monorepos, optimizing their development workflows and bolstering code sharing. The Monorepo discourse remains dynamic, with ongoing deliberations on best practices, tool enhancements, and strategies to navigate the intricacies of vast Monorepos.

Typical Fears about Monorepos

In this section, we will address some of the common apprehensions and concerns that software developers often have when considering the adoption of Monorepos, shedding light on the practical solutions and benefits that can alleviate these typical fears.

Scalability Concerns with CI Cycles

The Polyrepo approach often results in extended CI cycles, requiring complete rebuilds and retests for each commit—a decidedly non-scalable method, especially with numerous projects. However, adopting a monorepo paired with incremental build tools lets you rebuild and test only the segments affected by changes. While this method offers improved scalability, it is not a magic fix. For large repositories comprising numerous extensive applications, you might experience delays when making changes impacting multiple dependencies. While such scenarios are not frequent, they may necessitate leveraging multiple machines, also referred to as remote workers, to streamline the CI process.

Potential Git Limitations

There is a valid concern that standard Git tools may struggle with repositories comprising millions of files. Yet, it is vital to recognize that most Monorepos do not house thousands of applications. They typically comprise a handful of applications by a singular organization, housing thousands of files with millions of lines of code. Under these conditions, most tools can efficiently handle the workload.

Monolithic Deployment Concerns

A prevalent misconception is equating a Monorepo with forced simultaneous binary releases, based on the thought that Monoliths are disadvantageous. The source of this code and deployment considerations are two separate entities. Ideally, CI/CD best practices involve constructing and storing artifacts during the CI phase, deploying these stored items across various environments during deployment. Thus, accessing a repository should not be a requirement during deployment. Emphasizing, a Monorepo does not equate to a monolithic structure. Monorepos enable easy code sharing and inter-project refactoring, simplifying the process of developing libraries, microservices, and micro-frontends. This setup can offer greater deployment flexibility.

Unauthorized Code Changes

The fear that anyone can modify code within a Monorepo, potentially jeopardizing a team’s application without their knowledge, originates from an over-reliance on repository-level permissions. Several tools enable folder-level ownership settings. For instance, GitHub and other Git platforms provide a feature termed CODEOWNERS, allowing structured file creation as follows:

domains/domain-1/* @john

tools/scripts/* @peter

With the specified configuration, a pull request modifying domain-1 necessitates John’s approval. If it is solely about scripts, then Peter must give the nod. However, for pull requests touching both domain-1 and scripts, approvals from both John and Peter are essential.

This system enhances control over code ownership. To further understand its efficacy, consider the following example:

Figure 1.4: Project visibility in Monorepo helps to manage sharing between teams

In this example, the Dev Team 1 shares an API definition project between its frontend and backend projects. This API definition project is intentionally private, as both teams aim to preclude other teams from leveraging it. This choice stems from a desire to evade undue inter-team dependencies. If Dev Team 2 wants to use this API definition, it would obligate Dev Team 1 to accommodate additional requirements during modifications to the shared library.

In a Polyrepo environment, nothing deters teams from adding "api-definitions" to their dependency file (package.json, pom.xml, and so on). The dilemma? Dev Team 1 remains uninformed as these additions occur in an external repository. Contrastingly, most Monorepo tools, Bazel included, allow for precise library visibility delineation.

Monorepo is going to turn into a project’s spaghetti (dependency entanglement), making it challenging to comprehend and maintain applications

There is a prevalent misapprehension that Monorepos inevitably lead to entangled project structures. It is true that in numerous repositories, any given file could technically import another. While structured approaches do emerge through code reviews, these can deteriorate over time, resulting in intricate dependency networks.

For clarity, envision a medium-scale project. Chart out its component dependencies. Upon juxtaposing this with the actual repository, you may discern several surprising interconnections.

However, Monorepos empower developers to construct libraries with clear public APIs. The streamlined library creation process encourages more frequent library usage. Hence, a typical app often gets segmented into multiple libraries, interacting solely via their public APIs.

Monorepos endorse software modularization and detailed granularity. Their structure simplifies both the initiation of new projects and the refactoring of existing ones, particularly when expansion necessitates splitting.

Typical Challenges in Implementing a Monorepo

Implementing a Monorepo is not a smooth journey. Monorepos have their own challenges, and these are the most common ones.

Onboard development teams to new methods and tooling

Introducing new methods and tools typically comes with a learning curve. Developers must invest time and effort to grasp how these tools function and how they integrate into their workflow. This learning curve can impede productivity during the initial stages. People, in general, are often resistant to change, and developers are no exception. Many are accustomed to their current tools and methods, and introducing new ones can encounter resistance, potentially reducing morale and efficiency.

Integrating new tools and approaches with existing processes can be challenging. A seamless transition might necessitate adjustments to established workflows, and these changes might face opposition from team members set in their ways. Onboarding teams to fresh techniques and tools often demands more resources, like time for training and expertise to oversee the transition. Scarce resources can hinder the onboarding process.

Transitioning to novel methods and tools might interrupt ongoing projects. There might be concerns about potential delays or errors during the induction period. Compatibility challenges between new tools and current systems can pose significant obstacles. It is vital to ensure that new tools mesh well with the existing tech stack. Veteran developers, having profound knowledge of the prevalent tools, may oppose changes they deem superfluous or intrusive.

If the advantages of embracing new tools are not lucidly conveyed or do not offer evident value, team members might hesitate to adopt them. It is pivotal to offer ample training and sustained support for a smooth transition. Lack of adequate training or support can culminate in frustration and reluctance.

Choose the good Go to Monorepo strategy

Start by evaluating the scope of your projects. Decide which projects will pioneer the Monorepo approach and establish a roadmap for the rest. Monorepos thrive when handling multiple interconnected projects or components benefiting from shared code. Ensure your projects genuinely demand the integration and code sharing that monorepos provide. When selecting projects, account for your team’s structure and dynamics. Monorepos excel for teams on intertwined projects where collaboration and shared code are paramount.

For every project earmarked for migration, scrutinize your development workflow and procedures. Ascertain if a monorepo aligns with your current CI/CD pipelines and tools. The chosen strategy should enhance your workflow, not impede it. Also, gauge your codebase’s complexity. Projects with intricate interdependencies or significant reliance on shared code can find management simplified in a Monorepo. However, if your codebase is monolithic or made of broadly structured modules, consider refactoring into more detailed components.

Another vital aspect is versioning requirements. Monorepos typically necessitate a versioning system capable of managing distinct components separately. Determine if your team requires detailed version control for various code sections. The Monorepo structure’s design critically influences project scalability. As the codebase grows, Monorepos risk becoming cumbersome. Choose a Monorepo approach that can handle future expansion without significant performance hindrances. Be prepared for continuous refactoring during the Monorepo’s lifespan to optimize its structure.

Examine the tooling and support available for your strategy. Tools and frameworks tailored for Monorepos can simplify both the transition and ongoing management. Explore the presence of these tools within your organization’s ecosystem.

Transitioning to a Monorepo or a new methodology necessitates a shift in team culture and practices. Ensure your team embraces this shift, and you have laid out a robust change management plan. A Monorepo promotes long-term code consistency across projects. Ensure your strategy mirrors your organization’s long-term vision.

Lastly, remain receptive to experimentation and iterative approaches. The choice between Monorepo and Polyrepo isn’t set in stone. Experiment with one strategy and pivot to another if it aligns more with your evolving requirements.

Introduce Trunk-based Development

Monorepos typically do not synergize well with long-lived feature branches. As a result, you might need to adopt a trunk-based development variation and regularly employ git rebase. Transitioning to this style can be challenging for some teams as it introduces new practices, like feature toggles.

Trunk-based development is a strategy focusing on simplicity, collaboration, and swift delivery. At its heart, it pushes for continuous code integration into a shared branch, known as the trunk or main branch. This method contrasts with long-lived feature branches, where developers work separately for extended durations before merging into the primary codebase.

With trunk-based development, code changes are integrated into the main branch frequently, sometimes multiple times daily. This keeps the main branch updated and stable. Developers are urged to commit small, incremental changes, which eases code reviews, minimizes integration conflicts, and facilitates swift issue detection and resolution. Essential to this approach is automated testing. Automated tests run persistently, offering immediate feedback on code quality and correctness. Feature toggles or flags enable selective activation or deactivation of certain code features, allowing incomplete or experimental features to remain hidden until ready for release. This strategy enhances collaboration as developers consistently work on the main branch, with the absence of long-lived branches spurring more frequent code reviews.

Benefits of trunk-based development include:

Continuous delivery of new features and fixes.

Reduced software product time-to-market.

Minimized merge conflicts due to frequent, smaller merges.

Early issue detection and resolution, curtailing defect-fixing costs.

Elevated collaboration from a unified codebase.

Improved code quality and sustainability from concise commits and continuous testing.

However, implementing trunk-based development might mean:

Transitioning from feature-branch workflows, necessitating culture and practice shifts, including adopting feature toggles.

Handling complexities as developers use toggles to hide unfinished features.

Investing significantly in automated testing infrastructure since continuous testing demands ample resources.

Trunk-based development is considered to promote superior code quality and development pace, regardless of repo size. Still, it requires careful consideration. For instance, if you are on a feature branch and the trunk branch (also known as "master or main") gets new commits, rebasing your feature branch onto the main can position your work post those commits.

As for git rebase, it is a Git command allowing changes from one branch to be reapplied onto another. It is particularly useful in refining commit history and integrating branch changes. Rebasing maintains a linear commit history, unlike merging. While rebasing might encounter conflicts, they can be resolved before the process continues. Crucially, rebasing alters commit history. Pushed commits that are later rebased can create divergent histories, leading to potential confusion. It is wise to rebase only unpushed commits to shared repositories.

Mind the gap between Monorepo and your current tooling ecosystem

Adopting a Monorepo in an organization can yield significant advantages, but it is not without hurdles, especially when incorporating existing tools not tailored for Monorepos. A primary concern is ensuring tools, like static code analyzers (SonarQube, Find Bugs, and ESLint) or security linters (Fortify, Checkmarks, Veracode), mesh with the Monorepo structure. Many classic tools presume single-repository settings, making their integration into Monorepos potentially intricate and lengthy. Bringing in non-Monorepo tools often means custom development or outsourcing, leading to added time, cost, and potential vulnerabilities.

Reconfiguring CI/CD pipelines for Monorepos is essential. This may involve unique scripts or CI/CD tools adept at managing a Monorepo’s multifaceted build and deployment needs. Tools like Bazel, for instance, need a shared remote cache for all CI workers to bypass full rebuilds and effective repository management across CI cycles. Automated tests must be robust, ensuring a change in one component does not inadvertently disrupt another. Dependency management, especially across various languages or platforms, requires careful handling, and robust version control is crucial. As Monorepos expand, so do concerns over performance. Entire codebase operations can become time-consuming, demanding swift build and deployment techniques to counteract potential lags. Simultaneous issues across various components can complicate monitoring and debugging, necessitating proficient diagnostic tools and practices.

A Monorepo’s introduction can mandate a shift in development culture and practices. Teams may need to embrace new methods like trunk-based development or feature toggles, which might encounter resistance. Promoting effective team collaboration within the monorepo setting can be daunting, especially for those accustomed to secluded workflows. Therefore, clear code-sharing and ownership protocols are indispensable.

For a successful transition to Monorepos, organizations should meticulously plan their shift. This entails evaluating tool compatibility, making necessary tool adjustments or swaps, and ensuring teams have ample training and support. The long-term benefits of enhanced code sharing, efficient collaboration, and streamlined dependency management can make navigating these hurdles well worth the effort.

Deal with large-scale changes

Monorepos offer a streamlined mechanism for executing extensive changes in specific contexts. When refactoring various applications made of multiple libraries, a Monorepo ensures that every component operates seamlessly before finalizing the alteration.

Yet, Monorepos demand a nuanced strategy for sweeping changes, occasionally complicating certain processes. For instance, modifying a shared library affects every application dependent on it. If such a change is drastic and lacks automation, it necessitates backward-compatible adjustments. This means introducing dual versions of parameters, methods, classes, or packages and directing users to transition from the legacy version to the updated one.

The Power of Bazel in Monorepo Development

Monorepo development, which involves managing multiple projects or components within one version control repository, has earned substantial traction recently. Its capacity to enhance collaboration, promote code sharing, and refine dependency management sets it apart. Yet, with the growth and intricacy of monorepos, overseeing the build process across multiple programming languages and platforms can become overwhelming. Enter Bazel, the build tool tailored for such challenges.

Figure 1.5: Bazel in monorepo development

Bazel’s prowess is particularly evident in the realm of Monorepo development, especially when juggling multiple programming languages and platforms. Key attributes, such as its language-neutral approach, hermeticity, adept dependency management, comprehensive platform support, and emphasis on incremental builds and scalability, render it a top pick. Organizations aiming to tap into Monorepo advantages without compromising on build efficiency and dependability will find Bazel indispensable. In harnessing Bazel, development squads can sustain a unified and efficient workflow, supporting remote execution, even amidst the most multifaceted code environments.

A Bit of History

Bazel’s origins trace back to Google’s in-house tool, Blaze, developed in the mid-2000s. Created to tackle the mounting scalability and efficiency challenges of a rapidly expanding Google, Blaze introduced groundbreaking features. Notable among them were hermetic builds, ensuring build isolation from host environments, and a distributed caching mechanism, minimizing redundant build tasks.

In 2015, Google offered a slice of Blaze to the public, branding it Bazel. This open-source venture aimed to share Google’s scalable and reproducible build proficiency with the wider developer community.

The software realm soon noticed Bazel’s robust build, testing capabilities, and multilingual support. Recognized projects like Kubernetes and TensorFlow integrated Bazel into their build and test operations. Bazel’s developers kept broadening its linguistic scope, enhancing its appeal for polyglot projects. With contributions pouring in from diverse sectors, while Google remained a primary contributor, Bazel morphed into a collaborative open-source initiative.

In CI/CD pipelines, Bazel’s merits shine. Its commitment to hermetic, reproducible code building and testing complements contemporary software development ethos. Industry giants like Uber, Dropbox, and Pinterest have incorporated Bazel into their tech stack, signifying its pivotal role in sophisticated software infrastructures. With Bazel continually adapting to the dynamic software milieu, Google and its community persistently roll out enhancements, refining its capabilities, and expanding its versatility.

Bazel Features

Bazel is a distinguished build system created especially for Monorepos. It champions the principles of efficiency, scalability, and reproducibility in software development. Notably, it finds its niche in dealing with expansive codebases and intricate projects. Here are the core features that define Bazel’s proficiency in building and overseeing software ventures:

Local Computation Caching: This refers to Bazel’s adeptness in preserving and repurposing the outcomes of file and task operations. For individuals operating on the same computer, there is no necessity to redo builds or tests for the same tasks. When a specific command is given, it gets executed initially, caches the result, and subsequent invocations utilize this cached outcome.

Local Task Orchestration: Bazel is equipped to orchestrate tasks in a sequential as well as concurrent manner.

Distributed Computation Caching: This feature ensures that cached results are spread across varied environments. In essence, within an entire organization, including the CI agents, redundant builds or tests for similar components become obsolete.

Distributed Task Execution: Bazel can disseminate a command over several machines, all while preserving the feel of operating it on a singular machine. It is noteworthy that Bazel’s application here is incredibly sophisticated, capable of managing repositories with billions of code lines. Yet, setting it up might pose certain complexities.

Transparent Remote Execution: Bazel boasts the ability to unobtrusively run commands across multiple systems during local development, a unique trait that distinguishes it from its counterparts.

Impact Analysis: By assessing the potential ripple effect of changes, it permits the targeted execution of build and test processes for the impacted entities. Bazel might not natively offer this, but tools like target-determinator exploit Bazel’s query language to fill this void.

Workspace Analysis: Bazel has the prowess to fathom the project structure within the workspace sans extra configurations. Though Bazel expects developers to craft BUILD files manually, several firms have pioneered tools to auto-generate these files by scrutinizing the workspace content.

Dependency Visualization: With Bazel, one can visualize project/task interdependencies through graphical illustrations. This interface is interactive, bolstered by Bazel’s proprietary query language, ensuring precise information sifting.

Code Segmentation: Bazel facilitates easy sharing of code segments. Any directory can be flagged as a project and shared. This sharing is anchored by Bazel’s build protocols, promising a seamless developer interaction.

Uniform Tooling: Regardless of the tech stack—be it diverse JavaScript frameworks or languages like Go, Rust, and Java—Bazel guarantees a consistent experience. Its extensible nature, empowered by build rules, functions much like modules catering to varied tech landscapes.

Code Generation: While tools like NX or Pants natively support code generation, Bazel, in contrast, taps into external generators, offering a broader scope.

Project Regulation and Visibility: Bazel allows the crafting of rules to dictate dependency pathways within a repository. Developers have the liberty to earmark projects for their teams exclusively. Plus, tech-based categorization ensures no overlap between backend and frontend components. Bazel’s visibility protocols ensure a clear demarcation between what is shared and what is private.

Wrapping up, Bazel stands tall as a formidable build system addressing the nuances of today’s software development landscape. With its unwavering commitment to performance, reproducibility, and adaptability, it has won the favor of entities with sizable and multifaceted code repositories. Be it a Monorepo, a multi-language endeavor, or a distributed workforce, Bazel’s arsenal promises to elevate the development process, ensuring impeccable and swift builds.

Understanding the Logic Behind Bazel’s Design

Bazel is not just another build system; its foundational philosophy distinguishes it in a crowded ecosystem. To truly appreciate Bazel’s uniqueness, it is pivotal to grasp the foundational principles steering its design, including:

Reproducibility: A non-negotiable principle for Bazel. It understands the significance of consistent build results across varied settings. This is accomplished through rigorous dependency tracking and hermetic builds, ensuring they remain untouched by external