《持续交付》 - 组件和依赖管理
持续交付可以让我们每天发布软件的几个新的可用版本，这也就是说我们可以保持应用程序随时都可以正常运行，但当我们要对软件进行大型重构或者添加一些复杂的功能的时候，我们便很难对项目进行修改和快速发布，一般我们在遇到这种情况的时候可能选择的是在版本库上去新创键一个分支去进行，但这并不是持续交付所推崇的，我们尽可能的在同一个分支上去进行软件开发。所以在面对这种情况的时候我们应该将大型项目组件化。组件是指应用程序中的一个规模相当大的代码结构，它具有一套定义良好的 API ，而且可以被另一种实现方式替代。简单的说，在 JAVA 中，组件就相当与是一个 jar 文件，在 UNIX 平台上，组件就是一个 SO 文件......
一 保持应用程序可发步
在软件的开发过程中，当团队需要对软件添加新特性或者是进行大型的重构时，那么想要做到持续交付就非常困难，这个过程可能会长达几个星期甚至是一个月才能发布一个新的版本，这样显然不符合持续交付的观念。
1、 将新功能隐藏起来，直到它完成为止
如果团队想要开发一个新功能，而且这个开发周期很长的话，也没有增量式发布的需求。那么我们就可以将这个新功能隐藏起来，不让客户去访问（通过一个特定 URI 访问），当然了，在开发这个新功能的时候，一样是在主分支上进行。
2、 所有的修改都是增量式的
3、通过抽象来模拟分支
二 组件
1、如何将代码库分成多个组件
组件划分的好处
- 将问题分成更下且更达意的代码快
- 不同的代码可能有不同的生命周期
- 提高利用率
- 提供额外的自由度来优化构建和部署过程
当遇到下列问题时那么就应该创建组件
- 代码库的一部分代码需要单独部署
- 组件为其它系统提供接口
- 代码的编译和链接时间太长
- 在开发环境中打开项目的时间太长
- 对于一个团队来说代码库太大
2、 将组件流水线化
当我们把一个软件分成多个组件时，如果不是反馈太慢，那么就应该将整个系统作为一个整体来构建，这样我们就可以很快的去定位那哪一行代码破坏了构建，但如果系统较大且反馈时间很慢的话，那么我们就要对每个组件都进行单独的构建，且每个构建都应该部署流水线的模式来进行。
3、集成流水线
当每个组件执行完验收测试或手工测试后，那么集成流水线就开始了，它会将所有组件流水线中得到的二进制包进行组装并将这个组装好的二进制包部署到一个类生产环境上，运行冒烟测试，以此来验证集成是否有问题。 如果成功的话，那么接下来就进行验收测试。
