读【微服务设计】（五）部署

1. CI(持续集成)

CI技术已经出现很多年了（出书年是2015），因为在微服务之间的映射、构建以及代码库版本管理等方面，不同的考虑会有不同的选择。

CI能够保证新提交的代码与已有代码进行集成，从而让所有人保持同步。CI服务器会检测到代码并检出（check-out），然后花些时间来验证代码是否通过编译以及测试能否通过。

CI的好处有很多。通过它，我们能够得到关于代码质量的某种程度的快速反馈。CI可以自动化生成二进制文件，并且使用的代码都会归纳到版本控制，所以CI可以很方便的完成更新、测试、回滚的高度自动化，当然回滚是需要人操作的。

作者提出，很多团队正在做的CI并不是真正的CI，因为它们并没有严格遵循下面的操作：

• 是否每天合并代码到master？
  • 我们应该让自己和他人的本地代码尽快的与主线进行合并，如果没有就会导致将来的集成非常困难。即使你只使用生命周期很短的分支来管理这些修改，也要遵循此原则。
• 是否有一组测试来验证修改？
  • 如果没有测试，我们只知道集成后没有语法错误，但无法知道系统的行为是否被破坏。没有对代码行为进行验证的CI不是真正的CI。
• 当构建失败后，团队是否把修复CI当做第一优先级的事情来做？
  • 如果在构建失败后还允许继续提交修改，那么用于修复构建的时间就会大大增加。

2. 把CI应用到微服务

理想化的CI应该是：

1. 每个微服务都有自己的CI，这样就可以在将单个微服务部署上线时做一个快速的验证
2. 每个微服务都有自己的代码库，分别绑定相应的CI；当对代码库进行修改时，只运行相关的构建以及其中的测试。
3. 每个微服务的测试代码也应该和服务代码放在一起，这样就容易知道对于某个服务来说应该运行哪些测试。

如果你对某个服务负责，就应该同时对相关的代码库和构建负责。

3. 构建流水线和CD（持续交付）

作者说到在早些时候使用CI时，把一个构建分成多个阶段是很有价值的。比方说，测试环节包含了多个测试步骤，其中有的能够快速完成，有的比较耗时，如果所有测试一起运行，那一个快速测试失败后还得等待耗时测试的完成，这个等待其实没有意义，因为在一个测试失败时就应该立即停止构建流程。

解决这个问题的一个办法就是将构建分成多个阶段，从而得到我们熟知的构建流水线。在第一个阶段运行快速测试...

CD基于上述的基本概念，并在此之上有所发展。它能够检查每次提交是否达到了部署到生产环境的要求，并持续把这些信息反馈给我们。为了更好的理解这些概念，在这里我们把从代码提交到部署上线这个过程中所需要的流程进行建模。在CD中，我们会把多阶段构建流水线的概念进行扩展，从而覆盖软件通过的所有阶段，无论是手动的还是自动的。

下面是一个使用构建流水线建模的标准发布流程：

                         编译及快速测试——耗时测试——用户验收测试——性能测试——生产环境

我们需要一个真正重视CD概念的工具来辅助它的实施，作者提到，很多人尝试对CI工具进行扩展来做CD，这样的结果就是得到一个复杂的系统。所以，我们应该选择专门的CI和CD工具。

4. 结束

在书中本章的内容到此还远远没有结束，但对我个人来说，我认为没有记录的必要了，因为这些内容描述的多是一些七八年前的一些概念性的东西，我能够明显感觉到一些老旧过时的气息。当然这只是我个人的想法，如果读者有兴趣可以亲自去阅读本章剩余内容。

 

我找了一篇个人觉得还不错的描述CI/CD的文章，有兴趣可读。