14、微服务的持续集成与交付：策略、挑战与解决方案

微服务的持续集成与交付：策略、挑战与解决方案

1. 真正的持续集成

持续集成（CI）是一种让我们能够快速轻松地进行代码更改的关键实践，若不采用，迈向微服务的旅程将会充满痛苦。然而，很多团队虽声称在使用 CI，但实际上并未真正做到，他们常将 CI 工具的使用与 CI 实践本身相混淆。

Jez Humble 提出了三个问题，可用于检验是否真正理解 CI：
1. 是否每天向主线提交代码 ：需确保代码能顺利集成。若不频繁将自己的代码与他人的更改合并，未来的集成工作会变得更困难。即便使用短期分支管理更改，也应尽可能频繁地将其集成到单一主分支中。
2. 是否有一套测试来验证更改 ：没有测试，我们仅知道集成在语法上可行，但无法确定是否破坏了系统的行为。没有对代码预期行为进行验证的 CI 不能算真正的 CI。
3. 构建失败时，修复是否是团队的首要任务 ：绿色通过的构建意味着更改已安全集成，红色失败的构建则可能表示最后一次更改未成功集成。此时需停止所有与修复构建无关的提交，以尽快让构建通过。若让更多更改堆积，修复构建所需的时间将大幅增加。

2. 微服务与持续集成的映射

在考虑微服务和持续集成时，要思考 CI 构建如何与各个微服务对应。以下是几种常见的映射方式：

2.1 单一仓库和单一构建

将所有代码存于一个巨大的单一仓库，并进行单一构建。任何对该代码仓库的提交都会触发构建，会运行所有与微服务相关的验证步骤，并生成多个与同一构建关联的工件。

这种方式表面上比其他方法更简