持续交付发布可靠软件的系统方法（交付生态圈）第十三章：组件和依赖

《持续交付发布可靠软件的系统方法》读书笔记

持续交付让应用程序处于随时可发布的状态。在大型重构或添加复杂功能时，要继续保持应用的可发布状态，需要对大型应用组件化。
组件是指应用程序中的一个规模相当大的代码结构，它具有一套定义良好的API，而且可以被另一种实现方式代替。一个基于组件的软件系统，通常其代码库被分成多个相互分离的部分，每个部分通过有限的定义良好的接口提供一些服务与其他组件进行有限的交互。有人把组件称为模块。
基于组件的设计是一种良好的架构，具有松耦合性。

保持应用程序可发布

团队不断地增加新特性，可以给每次新特性创建新的分支，当新特性完成后，再将它合并到主分支。这将会导致合并周期变长，无法做到持续集成，这种方法不是最好的。提倡每个人都应该提交到主干。可是这样又该如何保证主干一直保持可发布状态呢？有如下四种策略：

• 将新功能隐藏起来，直到它完成为止。一种方法是把新功能直接放进主干，但对用户不可见，比如通过单独的URL来访问，通过Web服务器配置不允许访问其入口；另一种方法是通过配置项开关来管理。把功能半成品与系统其他部分一同发布是一个好实践。
• 将所有的变更都变成一系列的增量小修改，而每次小修改都是可发布的。首先需要用各种方式将一个需求分解成较小的任务，然后将这些任务再划分成更小的增量修改。
• 使用通过抽象来模拟分支的方式对代码库进行大范围的变更。在要修改的那部分代码上创建一个抽象层，然后在当前实现方法存在的同时，开发一种新的实现方式，当完成时再把原始的实现和抽象层删除。
• 使用组件，根据不同部分修改的频率对应用程序解耦。

依赖

库是团队除了选择权以外，没有控制权的软件包，它们很少更新。组件是应用程序所依赖的代码块，它一般由团队自己开发的，更新频繁。
构建时的依赖会与运行时依赖不同，管理依赖遇到问题。

• 依赖地狱。应用程序的依赖版本与实际部署的版本不一致。
• 库管理。一种方法是将库文件提交到代码版本控制库中，但时间久了后会导致版本库变大且乱，同时库文件的状态难以管理。另一种方法是使用显示声明的库管理工具，如Maven。

组件

只有一个系统达到一定的复杂度时，才会考虑将它分成多个组件。组件的目的是为了提交团队的效率。

• 它将问题分成更小更达意的代码块
• 组件常常表示出系统不同部分代码的变化率不同，且有不同的生命周期
• 将代码划分，也便于分析系统的职责描述和维护，并且提交了对代码的理解
• 提供了额外的自由度来优化构建和部署过程

当我们遇到以下情况时，可以考虑将组件代码从代码库中独立出来

• 代码库的一部分需要独立部署
• 打算将系统分成一个内核和一系列组件，以便用另一种实现代替当前系统的某部分或者支持用户自扩展
• 组件为其他系统提供了一个接口（如API接口）
• 代码的编译和链接时间太长
• 在开发环境中打开项目时间太长
• 对一个团队来说，代码库太大

大多数情况下，我们建议整个应用程序使用一个构建流水线，每次提交修改时，就应该构建并测试整个应用。只有当效率太低而无法忍受时，才使用并行流水线方式。

二进制包管理

使用制品库来管理二进制包，如Artifactory，Nexus。制品库不应该包含那些无法重现的产物，即便删除整个制品库，也可以方便地将二进制包恢复出来，一般通过重新构建对应的代码。
最简单的制品库是磁盘上的一个目录，最重要的是它应该将一个二进制文件关联到版本控制库中生成该文件的某个源码版本对应上。
流水线与制品库相结合

• 编译阶段会创建需要放到制品库的二进制文件
• 单元测试和验收测试阶段会从制品库中取出这些二进制文件，将生成的测试报告放在制品库中
• 用户验收测试阶段将二进制文件部署到UAT环境，用于手工测试
• 发布阶段从制品库中取出二进制文件，将它部署到生产环境