At the beginning

I’m not going to get into any technical discussions today, but I just want to throw out some ideas about engineering structures. There may be some for it and some against it, but I think the world of technology needs some discussion and exploration.

It doesn’t say that those are the optimal solutions, it’s probably just a personal opinion.

In fact, I have a little contact with both modes, of course, the article is also a personal point of view. Let’s take a look at the picture below, which is actually an original engineering structure, a silo structure, and a single silo structure.

What is a Monorepo

Monorepo means that the code for many projects is contained in a single code base of a version control system. These projects, while they may be related, are usually logically independent and maintained by different teams.

To put it simply, when we put all the codes in a warehouse and all students develop in this warehouse, this mode can be called Monorepo.

Many people think that this form is back to the single Project model that has not completed the componentization at the beginning. However, this is not the case, Monorepo will still have a hierarchical structure design, but also has all the components, but all the source code aggregation in a warehouse, each student is also in their responsible business module development.

What are the benefits of this? So what are his weaknesses? We’re going to talk about his brother, and then maybe a two-way comparison will show what it is.

What is a multi – repo

A project consists of several Git repositories, which are then grouped together by relying on aArs.

The solution of most companies on the market today is multi-repo in the form of multi-storehouse, and then plug-ins that synchronize multiple projects with aar version configurations.

Basically, each business becomes a separate repository, and then the base repository becomes a separate repository, and is developed in the form of relying on an AAR to introduce its dependencies on other repositories. I call this mode multi-repo.

In multi-warehouse mode, since each project is independent, unified configuration and dependency management are always difficult problems, but they are not without solutions. Many companies including me used to write a plug-in for cleaning dependent versions, and then put the dependent ext on the remote side. After that, it is provided to all business parties in the form of BRANC branches.

multi-repoThe problem of

When I used the hello encountered a scene, we depend on the business side of the code, then the business will also depend on the code with us, and then you become my first released a snapshot version to each other, and then they snapshot based on our version of code development, after I come back to a snapshot of the version update them again, for code development.

It’s probably fine in general, but in case someone accidentally changes the API method entry parameter or the name of some function. So in the final compilation stage will run is the method can not find the problem, and then the problem of crash, the number of times this problem should be very much.

Because of the isolation of the code, everyone develops independently in their own branches and warehouses, and is in a state of low awareness of others’ code, so naturally I think the code is in an unstable state.

Many companies end up compiling the final APK in full source code during the delivery phase. The idea is to switch source code plug-ins through an AAR and then bundle all the projects together to avoid unnecessary compilation problems.

There is the project reconstruction and project continuous upgrade, multi warehouse needs to set a CI/CD system for each project, there is branch management and other problems will constantly consume the energy of development, at the same time, because everyone is their own set of systems, there will be inevitable volume.

I heard a case a net friend said, because the aar is depend on the way, so they are in their own module directly dependent on the other side of the project, and then the other side of the project also rely on their aar product directly, in the practical development, this is dependent on cyclization must be avoided, but he is also not necessarily an error in the compartment.

In addition, some unified upgrade operations, such as AGP version upgrade, Koltin version upgrade, Gralde plug-in version and so on configuration information upgrade.

The code reuse rate in terms of multi warehouse may be a little lower. Every business may have some code implementation that may be better, but if you want to reuse the one that is relatively bad, it may involve a lot of CV code. A stable feature is fine, but if the code is still in the process of iteration, multiple warehouse is more prone to code risk.

multi-repoThe advantages of

Relatively speaking, the engineering structure of multi-warehouse is more independent, and each project has the ability to open independently. In this way, the learning cost of business students is relatively lowest, because they basically only need to be responsible for their own business modules, and they are more focused on what they need to care about.

Project synchronization and compilation are faster because most repositories are already compiled into AAR artifacts, so in warehouse mode, their synchronization and compilation are only responsible for the current project, and do not need to compile things unrelated to the current project, so it is faster in terms of speed.

It’s cheap to learn, because you’re responsible for the current project, so you just have to understand how the current project works.

The security is relatively higher, because the engineering structure is relatively independent, so for some relatively secret related projects, the security of the structure of the warehouse will be higher, even when you see the code does not have the right to make any code changes.

MonoRepoThe disadvantages of the

MonoRepo is slower to compile and takes longer to synchronize compared to warehouse mode. Because each project needs to reconfiguration the policy, switching aar dependencies to source code dependencies. And unlike aar dependencies, source-code dependencies require each project’s build.gradle, global configuration, plug-ins, etc., to be executed, so it takes a little longer. The normal Gradle-related life cycle is executed once for all source-compiled projects.

Toolchains can be relatively complex because all the source code is together, so the project may need to configure more NDK configuration environment, need more toolchains to coordinate these repositories to achieve the mixed state.

Relatively poor security, such as the relatively secret company core source code. Because of the single warehouse, access to the code is open to everyone. If there is source code leakage, it is relatively serious.

At the same time, the project volume will become very large, which will also cause the code that requires frequent rebase backbone during the coding process, and there may be a huge amount of code falling behind every day. But this one personally felt that it was within the range of expectation.

MonoRepoThe advantages of

To say the advantages of MonoRepo, in fact, are relative to the warehouse mode.

The first point to make is that your warehouse state is stable under development. In terms of the workflow, you cut off a branch, develop your business requirements on that branch, and then merge back into the trunk. However, compared with multi-warehouse, even if it is collaborative development, because everyone is using the source code, as long as the respective changes are visible on the spot. Each commit is relatively aware of what each other did, so this is a relatively stable slice. Even after we rebase the trunk, this part of the code is in a fairly stable state, because it is compiled and tested before it is incorporated. Even if the code changes, all changes are in a relatively stable state because of the syntax checks at compile time.

This I think is a very important point. In contrast to multi-warehouse, because everyone can submit code in their own warehouse, the submission of each other is isolated from each other, so we cannot predict whether the change of the other party will affect us, which leads to more risks. This is what MonoRepo calls atomic submission.

High participation and reusability of code, because all code is visible to everyone, so when we need some code we do not need to CV them directly, but can directly obtain their use rights through the form of dependency. In the case of the unstable state we talked about earlier, because everyone can participate in the changes, we can make our code more stable rather than patching.

MonoRepo also does not exist, depending on the characteristics of the compiler, when dependent on the case of the loop, the compilation will naturally report an error. This will avoid some of the errors.

More convenient code upgrade operation, before and we have introduced our current AGP version is relatively high version, the number of plug-ins is actually a lot, we also have plug-ins and other black technology. We also changed a lot of code at compile time. But because of our single warehouse structure, we only need to change one version number to make it effective for all warehouses. Fast and continuous iteration of the APP.

Single inspection tool, this part is to avoid repetitive construction work, because the warehouse is single, so only a static inspection of the current warehouse on the line, to avoid the risk of repeated wheel building.

conclusion

Thank you to see my nonsense finished so much, this article is actually just a point of view of the article, if you have different opinions in fact, we can discuss it.