preface

As the level of functionality and business increases, so does the level of front-end code, and the cost of managing operations increases further. Operational management challenges for code repositories also surface. There are two mainstream schemes: one is the decentralized independent warehouse of multirepo type, and the other is the centralized management of Monorepo type. Each has its own strengths, and the following is an in-depth understanding of the actual scene.

Decentralized management: Multirepo

That is, according to function or other dimensions, the project is divided into different modules and maintained separately in their warehouses.

Usage scenarios

For the new requirements of agile iteration and rapid development, the general practice is that each module corresponds to a warehouse, and the new requirements are classified. If they can be classified into existing warehouses, the iteration will be carried out.

advantage

1. Flexible

Different modules are maintained independently and are naturally isolated from other modules. Each module can choose its own style, tools, etc.

2. The security

Thanks to the module split, the authority control is more natural. Focus only on relevant parts of the development process and don’t mismanipulate the rest. Release online, no perception of other modules.

The problem

As a traditional way of management and organization, the development of such a long time, there are bound to be some limitations. It is highlighted in the cost of collaboration and administration.

1. Administrative costs

Common project handover, everyone is responsible for a pile of projects, accounts, etc., can only be manually sorted, there is also the possibility of missing. I went through a couple of big changes, and the transition was really confusing and heartbreaking. A need to find that there has been a warehouse in the forgotten corner.

2. Collaboration costs

When multiple projects are involved, local development requires opening multiple ides to switch between them. It is also a tedious process for local debugging and so on, although there are ways such as NPM Link.

3. Rely on upgrades

This scenario usually occurs with dependencies on core modules, especially self-developed base dependencies, which can be a long story to tell when they have to be upgraded, numbering up to hundreds of projects, each of which has to be modified and released once.

The above is the business module, for open source or internal infrastructure tools, the upgrade here is more significant. For both programmers, problems arise and problems are solved, hence the emergence of centralized management.

Centralized management: monorepo

The core idea of Monorepo is that all projects are in a code repository. Strict unity and return, in order to facilitate the unified upgrade and management. This is not to say that the code is not organized and stored randomly. On the contrary, it is more demanding to show an administrative structure on the file directory, otherwise it is less maintainable. For example, Babel, each module is in the specified Packages directory.

advantage

Since it is based on the evolution of the problem, in fact, the advantage is obvious, is the limitation of multirepo solution. For example, cost reduction of collaboration, operation management and so on. However, monorepo is not all beneficial. On the contrary, its limitations are obvious.

The problem

1. Project volume increases

As the project develops, the volume will gradually increase, and even become a few gigabytes of jumbo project size. Nature poses some problems:

  • The fetch time is longer

    Babel, for example, is only 130 megabytes, but that’s a lot of time, let alone the presence of G. Xxdy. Tech/img/mono. Gi… [GIF too big, always uploading failed, can only put a link…]

  • The increase in compile time is natural, and if you compile everything every time, the wait time for development and deployment can be quite long

2. The security

With all functionality exposed to all developers, security is a big issue. The possibility of misoperation, if relying solely on the quality of the developer and the manual rechecking of codereView, is not reliable.

The solution

Of course, for more mature patterns, the solution is also precipitated.

1. Multi-module management tool

For complex project modules, there is a natural need for practical management tools. Lerna, for example, describes itself as A tool for managing JavaScript projects with multiple packages.

2. Git sparse check out

Git can be used to create a solution for developers that only focus on content. Git supports sparse Checkout after version 1.7.

Sparse checkout means that only specified files are checked out from the local repository into the workspace without checking out all of them. Other unspecified files are not checked out (even if they exist in the workspace, their modifications are ignored).

That is, we can only focus on related modules in the workspace. Although all files are pulled down, the presentation and management will ignore other files. Even if other files are shown and modified, the changes will still be ignored. For example, in Babel we only show the babel-CLI content section as follows:

// Create a folder mkdir demo &&cdDemo / / initializes the git git init git remote add origin HTTP: / / https://github.com/babel/babel.git / / open the switch git config core. Sparsecheckouttrue// Specify a directoryecho "packages/babel-cli/">>. Git /info/sparse-checkout // git pull origin masterCopy the code

In this way, we can view the contents of the file only:

packages/babel-cli
Copy the code

Git /info/sparse-checkout (git/info/sparse-checkout

echo "packages/babel-cli/" >> .git/info/sparse-checkout
git checkout master
Copy the code

This increases security.

Extension: shallow clone

Sparse checkups are just part of the presentation and still contain all the files and history on their own. If you focus only on the most recent commit, you can do this by shallow cloning. Use:

git clone --depth 2 https://github.com/babel/babel.git
Copy the code

However, shallow cloning is more limited, and is generally used to view and study the remote version library.

  • Cannot clone a new version library from a shallow clone version library.
  • Other version libraries cannot get commits from shallow clones.
  • Other repositories cannot push commits to shallow clone repositories.
  • Do not push commits from shallow clone repositories to other repositories. Unless you confirm that the target repository contains all the historical commits that are missing from the shallow clone repositories, the target repository will contain incomplete commit history and the repository will be unable to operate.
  • When a merge is performed in a shallow clone repository, if the merged commit appears in the shallow clone history, the merge will go smoothly, otherwise a large number of conflicts will occur, as if merging with an unrelated history.

conclusion

This paper briefly introduces the concept of different warehouse management mode and some practice methods, personal understanding is limited, welcome to discuss. For more content, please turn to pear dream three villages.

Refer to the article

  • www.kloia.com/blog/monore…
  • www.worldhello.net/gotgit/08-g…
  • zhuanlan.zhihu.com/p/31289463