仓库&版本管理
Hi，我是阿昌，今天学习记录的是关于仓库&版本管理的内容。
当代码以及团队达到一定的规模以后，这会给项目仓库和版本的管理带来诸多问题。
一张常见问题的表格，不妨“对号入座”，看看项目有没有“中招”。
一、仓库管理
常见的有单仓模式和多仓模式。
1、单仓模式
单仓模式 指的是所有的组件代码统一在一个版本仓库中管理，团队成员基于一个代码仓库来完成日常的开发活动，就像后面图里画得这样。
这种仓库管理的方式的优点是简单，所有的代码在一起维护，团队所有成员能共享产品的所有代码。
由于所有代码都在一个仓库，所以代码集成方便，也便于团队统一代码规范。
团队之间能共享到所有人的代码，方便大家了解项目的整体代码情况以及学习其他组件架构及代码设计。
但单仓库的缺点就是当代码及团队规模庞大时，会带来后面的问题。
- 开发人员
容易受到干扰，不能专注在自己所属的组件代码上。 - 如果缺少有效的架构守护以及代码检视，因为代码都在一起，开发人员都有权限修改，就非常容易导致
架构腐化。
2、多仓模式
多仓模式 指的是各个组件在独立的代码仓库中维护，团队成员基于自己负责的组件仓库开发，不需要拉取自己不关心的组件代码。
多仓模式的优点是开发人员能够专注在自己维护的组件的代码开发上，不用每次更新所有的仓库的代码。并且仓库的代码量及复杂性是可控的，不同团队可以维护自己的仓库，职责清晰。
但是缺点是需要依赖拆分的组件足够独立，新增需求不用涉及跨组件修改，避免一个开发人员需要同时基于多个组件仓库开发。如果经常出现跨仓开发及修改代码，这样反而会降低开发效率。在实际项目中，具体采用哪种仓库管理策略，需要综合团队、代码规模和工程管理能力来考量。对于组件化架构来说，建议组件化项目初期采用单仓模式，等组件逐步稳定及团队规模达到一定的程度时，再考虑分离，即采用多仓模式。
二、版本管理
对于各个组件来说，直接都是依赖最新的代码，而并没有版本的概念。二进制依赖和之前源码依赖有什么不同，然后再一起动手对 Sharing 项目做二进制依赖改造
二进制依赖
二进制依赖 指的是组件之间不直接依赖源码，而是依赖组件编译生成的二进制文件，并且对这些二进制文件做版本管理，就像后面这样。
相比较源码依赖，在集成编译时，由于所有的依赖已经被编译成二进制的格式，所以可以有效提高版本的编译速度。这点是对于遗留系统改造的一个非常明显的收益。在之前的咨询项目中，见过大量的大型遗留系统，一次完整的编译都需要十几分钟。可以设想一下，如果开发每次修改代码都需要等待这么长的编译时间，那么就不会愿意频繁去触发编译来验证功能。
想要解决这个问题，采用组件化分而治之十分有效。另外，由于依赖的组件都是二进制格式，只能调用而无法修改原有组件的内容，这样能够减少代码被随意修改的风险。最重要的是，由于使用二进制依赖，可以对组件做二进制的版本管理，这样就能够更灵活组合各个组件的功能，而且当版本有问题时，也可以快速回滚集成之前的版本，重新发布。
当然，二进制依赖在带来灵活的版本管理时，也需要做一些额外的投入，主要是三个方面。
- 第一，需要
搭建二进制版本管理服务器，例如搭建 Maven 服务器来统一存放二进制组件以及管理组件的版本。 - 第二，在组件的迭代上，也需要
规划好组件各个版本的需求，并且做好组件的兼容性。 - 第三，在组件的二进制发布方面，也要结合持续
集成流水线让组件发布的过程自动化。不然以前依赖源码的时候，只需要改代码马上就能验证。但是如果是二进制依赖的形式，改完代码以后还需要发布新的版本，然后调用的地方依赖新的版本才能验证，这也会影响开发的效率。
三、Sharing 组件版本管理改造
以 Sharing 项目的日志组件为例，来看看如何做组件版本管理的改造。会使用 Maven 来管理组件二进制制品，为了方便演示，会使用本地 Maven 来配置，生成的制品会存储在本地的工程目录中。但在实际项目中，只需要把本地路径地址设置为自己搭建的 Maven 服务器的地址，就可以将制品发布到远程的服务中。这里我们的改造目标是，将日志组件发布到 Maven 仓库中，并将其他组件对日志组件的源码依赖调整为二进制依赖。
第一步，需要先在日志组件的 gradle 配置文件中引入 Maven 的插件，然后配置对应发布二进制组件所需要的 Maven 服务地址、组件名称以及版本号等信息，具体的配置代码是这样。
//日志组件所在目录的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'
}
}
}
配置完成后，就可以使用 gradle 命令来触发二进制制品的发布，代码是后面这样。
./gradlew :log:uploadArchives
成功执行完该命令以后，就可以在配置的本地地址目录下，找到对应生成的二进制文件，像后面这样。
最后一步，需要将之前依赖 log 组件源码的地方，调整为依赖生成的二进制制品。
implementation 'com.jkb.junbin.sharing.library:log:1.0.0'
当所有的调整完成以后，可以运行./gradlew testDUT 命令运行之前所有的测试，保证调整没有破坏架构规则以及业务功能。
四、总结
对于仓库管理来说，有 2 种常用的模式，分别为单仓模式以及多仓模式。
一张表，方便对比这 2 种分仓模式。
在实际项目中，可以根据代码以及团队成员的规模来选择合适的仓库管理模式，建议组件化项目初期采用单仓模式，等组件逐步稳定及团队规模达到一定的程度时采用分仓模式。
对于版本管理来说，采用二进制依赖的方式相比源码依赖能有效提高编译的效率。
另外，使用二进制依赖后，可以做组件的版本管理，这样可以更灵活地组合版本的功能。
在项目中，可以使用 Maven 来管理二进制制品的发布以及版本管理，具体可以参考Sharing 项目的改造示例。
如果组件已经是独立的仓库管理，而且组件间也都是二进制的依赖，那么日常开发中很重要的一项工作就是确保组件可以独立编译调试，避免每次都需要集成才能测试和验收。
