Warehouse & Version Management
Hi, I am 阿昌, what I learned to record today is about 仓库&版本管理content.
When the code and the team reach a certain size, this will bring many problems to the management of the project warehouse and version.
A table of frequently asked questions, you might as well "check your seat" to see if the project is "successful".
1. Warehouse management
The common ones are 单仓模式and 多仓模式.
1. Single warehouse mode
Single warehouse mode means that all component codes are 一个版本仓库managed in a unified manner, and team members complete daily development activities based on one code warehouse, as shown in the following figure.
The advantage of this warehouse management method is 简单that all codes are maintained together, and all members of the team can share all codes of the product.
Since all the code is in one warehouse, the code 集成方便is also convenient for the team to unify 代码规范.
Teams can share everyone's code to facilitate everyone's 了解项目的整体代码situation and learn other component architecture and code design.
But the disadvantage of a single warehouse is that when the code and team scale are large, it will bring about subsequent problems .
- Developers
容易受到干扰cannot focus on the component code to which they belong. - If there is a lack of effective architecture guards and code inspections, because the codes are all together and developers have permission to modify them, it will be very easy to cause
架构腐化.
2. Multi-position mode
Multi-warehouse mode means that each component is maintained in an independent code warehouse, and team members develop based on the component warehouse they are responsible for, and do not need to pull component codes that they do not care about.
The advantage of the multi-warehouse mode is that developers can 专注在自己maintain the code development of the components without updating the code of all warehouses every time. And for warehouses 代码量及复杂性是可控, different teams can maintain their own warehouses 职责清晰.
But the disadvantage is that the components that need to depend on splitting are sufficiently independent, and new requirements do not involve cross-component modification, which prevents a developer from needing to develop based on multiple component warehouses at the same time. If cross warehouse development and code modification often occur, this will happen instead 降低开发效率. In actual projects, which warehouse management strategy to adopt depends on the comprehensive team, code size and engineering management capabilities 考量. For the componentized architecture, it is recommended to adopt the single-warehouse model at the beginning of the componentized project, and then 一定的程度consider separation when the components are gradually stabilized and the team size is reached, that is, the multi-warehouse model is adopted.
2. Version management
For each component, it directly depends on the latest code, and there is no concept of version. What is the difference between the binary dependency and the previous source code dependency, and then work together to transform the binary dependency of the Sharing project
binary dependencies
Binary dependencies are between components 不直接依赖源码，而是依赖组件编译生成的二进制文件，并且对这些二进制文件做版本管理, as in the following.
Compared with source code dependencies, during integrated compilation, since all dependencies have been compiled into binary format, it can be effective 提高版本的编译速度. This is a very obvious benefit for the transformation of legacy systems. In previous consulting projects, I have seen a large number of large legacy systems, and a complete compilation takes more than ten minutes. It can be imagined that if the development needs to wait for such a long compilation time every time the code is modified, then it will not be willing to trigger compilation frequently to verify the function.
To solve this problem, it is very effective to use componentized divide and conquer. In addition, since the dependent components are all in binary format, they can only be called but cannot modify the content of the original components, which can reduce the risk of code being modified at will. Most importantly, due to the use of binary dependencies, binary version management can be performed on components, so that the functions of each component can be combined more flexibly, and when there is a problem with the version, the previous version can be quickly rolled back and re-released.
Of course, when binary dependencies bring flexible version management, some additional investment is also required , mainly in three aspects.
- First, it is necessary
搭建二进制版本管理服务器, for example, to build a Maven server to uniformly store binary components and manage component versions. - Second, in the iteration of components, it is also required
规划好组件各个版本的需求, and做好组件的兼容性. - Third, in terms of binary release of components, it should also be combined with persistence
集成流水线让组件发布的过程自动化. Otherwise, when relying on the source code in the past, you only need to change the code to verify it immediately. But if it is in the form of binary dependencies, after the code is changed, a new version needs to be released, and then the place where the call depends on the new version can be verified, and this will also work影响开发的效率.
3. Sharing component version management transformation
Take the log component of the Sharing project as an example to see how to modify the version management of the component. Will use Mavento manage component binary products, for the convenience of demonstration, will use local Maven to configure, and the generated products will be stored in the local project directory. But in an actual project, you only need to set the local path address to the address of the Maven server you built, and then you can publish the product to the remote service. Our transformation goal here is to publish the log component to the Maven repository, and adjust the source code dependencies of other components on the log component to binary dependencies.
The first step is to introduce the Maven plug-in into the gradle configuration file of the log component, and then configure the Maven service address, component name, version number and other information required to publish the binary component. The specific configuration code is as follows.
//日志组件所在目录的build.gralde 文件配置
apply plugin: 'maven'
group = 'com.jkb.junbin.sharing.library'
archivesBaseName = 'log'
version = '1.0.0'
repositories.mavenCentral()
uploadArchives {
repositories.mavenDeployer {
repository(url: 'file:'+ rootDir.getPath()+'/lib')
}
}
//根目录的build.gralde 文件配置
allprojects {
repositories {
maven{
url 'file:'+ rootDir.getPath()+'/lib'
}
}
}
After the configuration is complete, you can use the gradle command to trigger the release of the binary product, the code is as follows.
./gradlew :log:uploadArchives
After successfully executing the command, you can find the corresponding generated binary file in the configured local address directory, as shown below.
The last step is to adjust the places that previously relied on the source code of the log component to rely on the generated binary products.
implementation 'com.jkb.junbin.sharing.library:log:1.0.0'
After all the adjustments are completed, you can run the ./gradlew testDUT command to run all the previous tests to ensure that the adjustments do not break the architectural rules and business functions.
Four. Summary
For warehouse management, there are two commonly used modes, namely single warehouse mode and multi warehouse mode.
A table is convenient for comparing these two warehouse allocation modes.
In actual projects, you can choose the appropriate warehouse management mode according to the code and the size of the team members. It is recommended to adopt the single warehouse mode at the beginning of the component project, and use the warehouse mode when the components are gradually stabilized and the team size reaches a certain level.
For version management, using binary dependencies can effectively improve compilation efficiency compared to source code dependencies.
In addition, after using binary dependencies, version management of components can be done, so that the functions of versions can be combined more flexibly.
In the project, you can use Maven to manage the release of binary products and version management. For details, please refer to the transformation example of the Sharing project.
If components are already managed in independent warehouses, and there are binary dependencies between components, then a very important task in daily development is to ensure that components can be compiled and debugged independently, avoiding the need for integration every time for testing and acceptance.