This article is an article to think about repository operation to enjoy the merits of monorepo development in a project to develop Java FW.
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 **.
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.
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.
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.
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.
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
}
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.
Compared with the operation of the mono repo, the evaluation of the repository operation of the team is as follows.
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.
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.
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
Recommended Posts