Code library Management Case Analysis

I participated in a project in the company the other day.CodeLibrary management policy. In the past, there were many similar discussions during the customer's consultation, but the customer's situation is relatively stable, and the similarity between projects is relatively high, so there are not many options. In this discussion, because it happened in thoughtworks, everyone was in a completely equal position. They opened up the discussion, but actually made the original rigid theory really alive.

Background

CWP is a relatively large project within thoughtworks with more than 30 people. Of course, this is incomparable with the project we consulted. However, thoughtworks advocates small teams. We think that more than 10 teams should consider splitting, which is good for project management, team communication, and architecture isolation. The project was originally focused on a product, the product, the recently prepared to join the MTL product, we think this is a good time. The user-defined procedure (MTL) and the user-defined procedure (MTL) are used to manage an account. We want to extract this function into an account setting product, because other products will depend on this function in the future. Due to human resource restrictions, account setting should be put into the MTL team for development, and the integration of User-Agent-agent (MTL) and account setting should also be put into the MTL team for development. Some of the account setting functions have been implemented in the User-Defined Identity Management (SCM.

Discussion

A basic problem is whether the code library is separated or combined.

First, you can work either separately or together. Second, both separation and combination have relative disadvantages. It seems very simple. Failing to acknowledge these two points without prior clarification often leads to a deadlock in the debate. In addition, not only was it emphasized at the beginning, but it had to be said repeatedly throughout the process. So is this not the case? Yes or no. At this level, it is a mixture of mud. Further analysis of which method will bring any benefits and disadvantages is not a mixture of mud.

First, let's look at the benefits of integration. The dependencies between these products are obvious, especially when these products are developed by the same team. We put the code together, and the natural benefit we can achieve is version alignment. One product depends on another product in several ways: API dependency, RPC dependency, and rest dependency. We use rest dependencies, but there is also a private protocol dependency. If the code is combined, because we adopt the practice of continuous integration, we can ensure that all versions I release can work together at any time-whether it is an exchange interface or a protocol.

What are the disadvantages of integration? The disadvantages and benefits are actually very similar. Because of the forced version alignment through code management tools, the dependencies between different products are actually tied to death. Account setting has upgraded its own protocol, and must be updated at the same time. Otherwise, continuous integration will fail.

The benefits and disadvantages of separation are basically the opposite of those of integration. Separation means flexible version collaboration, but also requires someone to coordinate the alignment of different product versions. There is also version library management-developers may need to switch between different version libraries.

Tangle

In addition to the analysis of the above advantages and disadvantages. Some operations may produce the opposite result. For example, separation may also increase or decrease communication costs. The combination is more convenient for joint debugging, because the code on both sides is together, I can change the code on the other side, so that they can work together; the combination also promotes the neglect of interface design, which leads to closer coupling between the two sides and increases opportunities for communication. We say that the correct mode of communication is that there is no need to communicate. We can separate the two, so that both parties are more concerned with interface stability and reduce dependencies.

What should I do?

Benefits-disadvantages, disadvantages-benefits, confusions-tangle, if you continue to discuss the problem within, there will never be a conclusion. Therefore, you must jump out to see the background of the problem. Whether we want a strict version alignment or flexible version collaboration.

We noticed that more products will be added to depend on account setting in the future. Keep all product versions aligned, especially during development. So let's separate them.

I don't mean that separation is right. I can only say that separation is a good choice. Or, in the words of Mr. Churchill, separation is the worst choice except for integration. Even if it is better than the combination, I cannot guarantee it. The value of this discussion shows us what benefits are brought about by separation and what problems are avoided. -- Enough!

Version dependency management

The code library is separated. The next step is how to build the continuous integration environment. Considering that account setting may release multiple versions, different products may depend on different versions. One way is to set up the environment to the account setting team, maintain an environment for each version, and connect other products to this environment for continuous integration. Another way is to set up the environment to various products. You have to decide which version you want to depend on.

This reminds me of one thing that happened when I consulted a company. Department A of company I is divided into multiple teams of platforms and products. After the platform releases things to the product, it takes less than a week or two to complete the integration of a version, and more than a month or two to complete the integration. The versions released on the platform are often unavailable in our product department. We have built a continuous integration environment in the product department, but it has little effect. So where should the environment be built? We think we should go to the platform department. If you want to deliver something to me, you should be responsible for this quality.

From our perspective, we seem to have to go to the account setting team. However, this analogy is quite slow. Account setting should be released externally, ensure the quality, and set up an environment for product integration. This is no problem. However, if the product's continuous integration environment is put on the account setting side, the problem is big. -- Coupling! The four products of ABCD may depend on account setting version 1.0. Is it true that the continuous integration of any of them fails? Do I need account setting to locate the issue? In more complex cases, a product may need to be associated with a minor version, which may result in explosive combinations at account setting.

So good, I have set up the environment to the product. Now product A has a version 1.0 environment. to jointly develop a feature, you need to upgrade it to version 1.1. This feature is developed by dev1 of product, if you upgrade the 1.0 environment in product A, the local build and submission of building by others will inevitably fail. If you do not upgrade, the local build and submission of dev1 will inevitably fail.

This is a typical environment management issue in continuous integration. Ensure consistency between local build and commit build during continuous integration. For this consistency, the dependency on software and hardware should be clearly defined and managed in a unified manner.

Continuous Integration Environment Management

In typical continuous integration, software dependency management is to manage software dependencies. That is, the release package of account setting is put into the code base of product A. The release package of product A depends on the version of. A release package can be rolled back if the build fails. In this way, both local build and commit build depend on a version release package.

This is not our final solution. The final solution we chose is as to put our own release package into a public accessible warehouse. Other products can reference release packages of different versions, similar to the maven mechanism. The principle is similar to that mentioned above. In fact, this is also a configuration management.

Such a discussion involves configuration management, testing, environment management, processes, and organizational structure. Basically, in addition to reports, all dimensions related to continuous integration are involved.

The end.