Introduction
A monorepo (short for “monolithic repository”) is a development strategy in which all code for multiple projects is stored in a single, centralized repository. This is in contrast to a traditional repository-per-project approach, where each project would have its own repository.
When can it be used
In Seagen, monorepos are supported. A monorepo can be used when multiple related projects share a lot of code and dependencies. By storing all the code in one place, it can be easier to manage dependencies, enforce consistent coding practices, and share code across projects. This can be especially helpful when your team has many interdependent projects.
One popular use case for monorepos is in front-end web development, where many different projects may use the same UI components or libraries. By storing these components in a shared monorepo, developers can make changes and improvements that automatically propagate to all the projects that use them.
What are some challenges with monorepos
However, monorepos can also have drawbacks, including longer build times and the potential for conflicts and collisions when multiple teams are working on the same codebase. So it’s important to carefully consider the specific needs and challenges of your team before deciding whether a monorepo is the right approach for our applications or work. Switching from a monorepo to a single app repo is extra work and will be time consuming. Choosing properly at the start will reduce frustration, extra work, and complexity.
Who are using monorepos today
There are many companies using monorepos today. Though these all point to a single source code base for all projects, Seagen does not use this approach and leaves the decision up to the development team. While we can support monorepos, the pipeline work will need to be done as explained later.
Google: Google’s monorepo is famously large, containing all of the company’s source code for every project. The monorepo contains over 2 billion lines of code and is managed using the company’s proprietary version control system, called Piper.
Facebook: Facebook also uses a monorepo to manage its codebase, which includes the source code for all of its products, including the Facebook app, Instagram, and WhatsApp.
Microsoft: Microsoft has also moved towards a monorepo strategy for some of its products, including Windows and Office. By storing all the code for these products in a single repository, developers can more easily share code across different teams and work on related projects in a coordinated way.
Airbnb: Airbnb’s monorepo, called “Monorail”, contains the code for all of the company’s web applications and services. By using a monorepo, Airbnb is able to more easily share code and manage dependencies across its many projects.
Babel: Babel is an open source tool for compiling modern JavaScript code to be compatible with older browsers. The project uses a monorepo to manage its various packages and plugins, making it easier to share code and enforce consistent coding practices.
Within Seagen, Research Data Hub, Launchpad Manufacturing and Launchpad Global IT Operations are good candidates for monorepos.
These are just a few examples of the many companies and open source projects that use monorepos to manage their code base.
What to consider when creating and using a monorepo
When Seagen uses a monorepo (a single code repository that contains multiple projects or components), there are some changes that need to be made to the Continuous Integration and Continuous Delivery (CI/CD) pipelines to ensure that they work effectively. Here are some of the changes that need to be considered:
Build and test only what has changed: In a monorepo, it’s common for multiple projects to share the same codebase. Therefore, it’s important to ensure that the CI/CD pipeline only builds and tests the components that have changed, rather than the entire repository. This can help to reduce the build time and speed up the feedback loop. It also requires more pipelines to support many projects with many changes.
NOTE: monorepos do not imply that you take multiple apps and make their deployment pipeline interdependent. Be as distributed and explicit as possible. If there are dependencies on resources being deployed first, make that dependency and nothing else.
Parallelize builds: Since a monorepo can contain multiple projects, it’s important to parallelize the build process to take advantage of the available resources. This can help to speed up the build and test process, and reduce the time it takes to deliver changes. Remember, build agents are finite and the entire organization uses the same agents.
Version control and package management: A monorepo can make version control and package management more complex. It’s important to have a good system in place to manage dependencies and versioning across multiple projects. This can include using tools such as lerna or Bazel to manage dependencies and versioning. It should also include artifactory to help manage dependencies.
Pull request management: In a monorepo, it’s important to have a good system in place for managing pull requests. This can include using tools like GitHub’s pull request review process, which allows multiple reviewers to review changes across multiple projects. As a standard, all branches are protected by branch protection unless you are working in exception areas of Statistical Programming. Otherwise, pull requests are enforced in GitHub.
Deployment strategies: Since a monorepo can contain multiple projects, it’s important to have a deployment strategy that can handle deployments across multiple components. This is accomplished by promoting from development to staging to production.
Monitoring: GitHub has a good monitoring system in place to track changes across multiple projects. This includes using tools such as Grafana or Prometheus to monitor changes and detect issues in real-time.
Overall, when using a monorepo, it’s important to have a well-designed CI/CD pipeline that can handle the complexity of managing multiple projects within a single repository. By making the changes outlined above, Seagen can ensure that their CI/CD pipelines are effective, efficient, and scalable.
Next steps
If you are evaluating monorepos do the following.
Identify apps
Identify dependencies between them
Understand and document how you will manage releases
Design pipelines to deploy packages and not the repository