Introduction

This article is an article to think about repository operation to enjoy the merits of monorepo development in a project to develop Java FW.

What is Monorepo?

Simply put, it is a repository operation strategy that manages code across modules in one repository. There are the following two ways of thinking about monorepo, but in this article we will consider the ** latter **.

The idea of managing all corporate code in one repository
The idea of managing all the code of a project module in one repository

Is this a mono repo?

My team is developing Java FW. The FW consisted of several modules, which were developed in one Git repository. When I asked the team about the reason for this repository structure, it was said that the repository was created within the range of quality assurance as a product. At that time, I had little experience with Git, so I didn't feel uncomfortable, but it seems that the operation of such a repository is called monorepo, so I will investigate whether it is an operation that makes use of the merits of monorepo operation.

Benefits of Monorepo

With reference to the document of Nx, which is a toolset for monorepo development, the following four points can be mentioned as the merits of monorepo operation.

Code is easy to reuse because all the code is in the same repository and can be referred to each other.
The impact of module changes is complete within the same repository and can be resolved with 1PR.
Consistent build and test procedures for modules using different tools and technologies.
Dependencies for each module can be fixed to a single set without suffering from dependency conflicts later.

Look back at the team's Java repository

From the following two points, it can be said that the repository is enjoying the benefits of monorepo. As a matter of fact, we don't throw PR to repositories here and there as we develop and modify features, and we don't have to worry about dependencies as a consolidation test.

1. Modules that make up the product are managed in the same repository

The modules, including the test code, are developed in the same repository, and you can refer to each other and check the impact of the changes (* The image structure is an image). If the repository contains a file that defines a pipeline job (.gitlab-ci.yml), such as GitLab CI / CD, the pipeline Another advantage is that jobs can be easily reused.

2. Dependencies are uniquely managed in the gradle file

Product dependencies are managed in a single gradle file.

dependencies {
	implementation("org.aspectj:aspectjrt:1.9.4")
	implementation("org.aspectj:aspectjweaver:1.9.4")
	implementation("com.fasterxml:classmate:1.4.0")
	implementation("commons-beanutils:commons-beanutils:1.9.3")
	implementation("commons-betwixt:commons-betwixt:0.8") {
		exclude module: "commons-beanutils-core"
	}
    //Omission
}

Operation of mono repo

As mentioned above, we were able to confirm that the team was benefiting from the mono repo. Next, let's consider the considerations for monorepo operation in order to maximize the benefits of monorepo and address the operational issues of monorepo. This is based on references. See also the references at the end of this article.

** 1. How to deal with the increase in physical repository size ** The repository is bloated because all the code is managed in a single repository. Not to mention the size, you need to consider how to deal with the increased build and test time. In general, control to build and test only the area of influence.

** 2. How to protect modules that you don't want to be tampered with ** If all modules are stored in a single repository, another team can destroy the modules. It will be considered to provide control for each team for the module.

** 3. How much can a single standard permeate each module ** If the coding style, quality control standards, and dependency sets are different for each module, the benefits of monorepo will be lost and management will become complicated. The workaround is to enforce the de facto standard on the module.

** 4. Can module changes be quickly spread throughout the repository **? The merit of mono-repo operation is that all developers can refer to the latest code of all modules. Therefore, trunk-based development based on CI / CD is considered preferable for repository operation.

Review the team's Java repository operation

Compared with the operation of the mono repo, the evaluation of the repository operation of the team is as follows.

The repository and development team are not huge.
Due to the nature of the project, it is not developed by a large number of teams.
As a product, ** heavy quality control ** is stipulated, and certain standards are unified among modules.
Developed with feature branch.

The team is accelerating the reflection of code changes by promoting CI / CD for quality control. In addition, since the developers are in control of the entire repository in the development with a small number of teams, it can be said that there are no problems due to the repository size or development scale.

Summary

We explained the merits and operation method of developing with mono repo, and confirmed the team's mono repo and its operation. In conclusion, the team's repository did not have any major issues regarding monorepo operation, and it was developed while receiving benefits. In a repository developed by a small team, it can be said that there are not many problems caused by making a monorepo.

As an aside, it feels a little strange when the repository and repository are lined up.

References

Regarding the mono repo, the merits and operational studies are described based on the following references.

--Nx documentation: https://nx.dev/angular/getting-started/why-nx

Misconceptions about Monorepos: Monorepo != Monolith：https://blog.nrwl.io/misconceptions-about-monorepos-monorepo-monolith-df1250d4b03c --Translation: https://www.graat.co.jp/blogs/ck1099bcoeud60830rf0ej0ix --Monolith → MultiRepo → MonoRepo Repository Strategy: https://slides.com/kotamat/repository-strategy

I noticed that I am developing Java FW in the mono repo, so I will consider the operation.