An initial conversation of repository quickly tends to switch to branching strategy or dependency management.
What is the real impact of mono or multirepo on the architecture, the organization and the development processes?
This is what we are going to share decrypting the main myths around the famous repository models.
Get the context of repos reading these introductory articles The Epic Story of Mono vs. Multi-Repo is Not New and The Hands-on Mainstream Repo Models You Need To Know.
Join the QE Unit to access more exclusive content from the community.
Your Repo is not your project architecture
Your repository is the storage of the source code, in particular the projects of the various applications.
The internal organization of your project largely reflects the chosen architectural style, whether in SOA or microservices.
You can store your projects, their directories and subdirectories as you wish, whether in mono or multi-repos.
The architecture of your application is therefore a much broader theme, the repository of which is one of the supporting elements.
Monorepo! = monolith; Multirepo! = microservices; continue;
Antoine Craske
Different levels are to be considered in the architecture of your application:
- The overall architecture of your Information System (IS)
- The architecture by engineering context (eg Front- office, Back-office, Data)
- The local architecture of a particular application
The chosen style of architecture can be aligned between different contexts, even if its tendency will be towards diversification through growth.
Certain architectures are more suited to a particular repo model, in an equally aligned organizational context.
For example, a distributed microservices architecture supported by decentralized teams will be more suitable for a multi-repo model.
This is the case with Spotify and Netflix.
It should be remembered that:
- The style of architecture and the model of repository are different choices
- An architectural style must be analyzed at different levels, just like your model of repository
- There is a need to coordinate your decision of repository and architecture by their adherences
Your Repo is not your branching strategy
Let us continue our analysis in the development process.
What is the impact of trunk-based development, gitflow and other branch management models on the subject of repos?
Let us take some examples.
We want to set up trunk-based development at scale à la Google and we ask ourselves the question of mono versus multirepo.
Both models are possible.
Their implementation will have different implications depending on the models:
- The mono-repo model requires more specific tooling such as CI/CD processes
- The multirepo will be reduced to a more localized and decentralized implementation of pipelines of builds and releases by projects
The same logic applies to other branching and resting models.
What you need to remember on this topic:
- Your branching strategy is not your repo model
- The implementation of your branching strategy has different implications depending on your repo model
Your Repo is not your dependencies management
“Dependencies”, the software nightmare, we would love to be able to get rid of them.
Some examples of dependencies:
- The version of Java used by the projects
- Your standard internal logging library
- A “core” project for shared business object model
The reality is that this complexity exists and will have a tendency towards entropy, hence the need to contain it.
The management of the necessary dependencies can be approached, as for repos, with two approaches:
- Centralized: the famous common libraries and functions
- Decentralized: the famous sin of the code duplication
Each can be implemented regardless of your repository model.
You can duplicate code, being functional or technical, in different directories of your monorepo or multirepos.
You can also choose to use libraries referenced between projects on the two models.
Each of the models has different implications in your repository.
A monorepo will make it easier to have a global view, for example on duplication, or to update dependencies more directly.
Conversely, visualizing duplicate code between various repositories will be more difficult to visualize.
What to remember:
- The repository model is not your dependency management
- You can combine various dependency management modes
- Your dependency management mechanisms must be adapted according to your repo model
Your Repo is not your versioning management
The logical continuation of dependencies leads us to versioning management.
We will skip the subject of the choice of Git, SVN or other version control systems (VCS), which has tended to standardize for Git (hopefully understood and used wisely).
Let us focus here on the strategy and practices of versioning:
- What naming rules for our artifacts? (eg major.minor.fix)
- What policy for updating internal libraries?
- What are the practices for updating public APIs?
So many questions that you must answer and set up regardless of your choice of repository.
As for the other subjects, their implementation, visibility and maintenance will be different depending on the repo model.
I will pass you the two points of conclusions which are beginning to repeat themselves.
Your Repo is not your release pipeline
You could almost think of working in the oil industry talking so much about pipelines.
Their process consists of three main stages:
- Build: Construct the artifacts
- Deploy: Deploy in the different environments
- Release: Activate the services, more or less gradually
The link with your repo is quite structuring, at least the Build step will contain the path to your configured repository.
If your project has a core dependency updated, it will need an update at some point.
If a project has disorganized directories, mixing technologies by directories, you will probably need to sort and organize this before you can configure your pipelines.
The strongest link between your pipelines and your repository model is therefore rather located at the project and application level.
The split-repo model, on the other hand, is the most structuring one in relation to your pipelines, having an additional directory separation step before you can build your application.
Same conclusion: different subjects, with more or less strong adherences, depending on the model.
Your Repo is not your engineering culture
A monorepo will not make you become Google.
Unfortunately, a multirepo won’t turn us into the next Spotify or Netflix either.
On the other hand, these major players heavily weighted their repo decision according to the engineering culture they wished to develop.
Keep in mind the different notions of correlation and causation.
You won’t become Google just by adopting a monorepo, sorry.
Antoine Craske
Google has invested heavily in its monorepo which has demonstrated its ability to expand and even accelerate commits over the years.
A culture of global sharing, of building a common product and practices such as trunk-based development is at the heart of their processes.
Spotify has also invested heavily in its engineering culture on a more decentralized model supported by a multirepo one.
In both cases, the models have supported the growth and expansion of the organization.
The key point is that an alignment of the repository model with the architecture of the company, the organization and the applications will be truly supporting.
Your Repo is structuring but not everything
The sharing of these different myths reflects the importance of the choice of repository.
The repeated pattern around those myths is that they are different subjects, not restricting your repo model, but that must be taken into account for a performant system.
Understanding the different models remains fundamental to identifying and aligning the impacts in the various processes.
This is the subject of the upcoming mono and multi-repo guide.
References
https://hackernoon.com/mono-repo-vs-multi-repo-vs-hybrid-whats-the-right-approach-dv1a3ugn