5 min to read
Microrepos vs Monorepos
A lot vs just one
Source code, what is that?
Source code in version control refers to the practice of managing and storing the code of a software project using a version control system (VCS). A version control system is a tool that helps track changes to files, typically source code files, over time. This allows multiple people to work on the same project simultaneously, track the history of changes, and revert to previous versions of the code if necessary.
The key aspects of source code in version control include:
- Version Tracking: Each change made to the source code is tracked and recorded with a unique identifier, often called a commit or revision. This includes information about what was changed, who made the change, and when it was made.
- Branching and Merging: Version control systems allow developers to create branches, which are parallel versions of the source code. This enables developers to work on new features or fixes without disturbing the main codebase. These branches can later be merged back into the main codebase.
- Collaboration: Multiple developers can work on different parts of the same project simultaneously. Version control systems manage these concurrent changes and help resolve conflicts when merging different changes.
- Backup and Restore: The version control system serves as a backup, allowing developers to revert to previous versions of the code if something goes wrong with the current version.
- History and Audit Trail: The complete history of changes to the source code is maintained, providing an audit trail for what changes were made, by whom, and why.
- Code Review and Accountability: Version control systems facilitate code reviews by allowing other team members to examine changes before they are merged into the main codebase, fostering accountability and quality control.
Both “Microrepos” and “Monorepo” are strategies for storing source code in version control systems like Git. They each have their advantages and disadvantages, and the choice between the two often depends on the specific needs of a project or organization.
Microrepos (Multiple Repositories)
In a Microrepos setup, each project or service has its own separate repository. This is the traditional way of organizing source code and is often the default for smaller projects or organizations.
Advantages:
- Isolation: Each repository is isolated, making it easier to manage permissions, dependencies, and continuous integration/continuous deployment (CI/CD) pipelines.
- Simplicity: Smaller codebases are easier to understand and manage.
- Flexibility: Different projects can be written in different programming languages, use different build systems, and have different owners.
Disadvantages:
- Dependency Management: If projects depend on each other, keeping them in sync can become challenging.
- Code Reuse: Sharing code between projects may require additional tooling or processes, like shared libraries or submodules.
- Operational Overhead: More repositories mean more configurations, more pipelines, and more places to manage access controls.
Monorepo (Single Repository)
In a Monorepo setup, multiple projects or services are stored in a single repository. This is a strategy often used by large organizations like Google, Facebook, and Microsoft.
Advantages:
- Unified Versioning: A single repository means a single history, making it easier to keep versions of different projects in sync.
- Ease of Code Reuse: With all code in a single repository, it’s easier to share code across projects.
- Simplified Dependency Management: Dependencies are easier to manage when all code is in one place.
- Atomic Commits: Changes across multiple projects can be committed together, ensuring consistency.
Disadvantages:
- Complexity: A large codebase can be difficult to manage and navigate.
- Resource Intensive: As the repository grows, operations like cloning, pulling, and fetching become slower.
- Access Control: It can be more challenging to manage permissions in a granular way.
Summary
This is my own personal opinion, as for my past experiences:
- Microrepos: Better for smaller, isolated projects with different stacks and less interdependency. Developing APIs, Frontends, microservices, etc.
- Monorepo: Better for larger projects with a lot of shared code and interdependencies, but requires good tooling and practices to manage effectively. Developing big stacks of components that are tightly related, such as a platform for deploying multiple Kubernetes clusters and then their workloads (deployments, config maps, etc.).
The choice between Microrepos and Monorepo often comes down to the specific needs and constraints of your team or organization, for the last 7 years of working with multiple teams and projects all around the world, I have seen both. They do the job well if the teams are also following best practices when using source code and developing not just code but also infrastructure.
References.
Build On!
