微服务运维实战：Docker容器持续集成

Continuous Integration with Docker Containers

我们知道得越多，从绝对意义上来说我们就变得越无知，因为只有通过启蒙，我们才能意识到自己的局限性。智力进化最令人欣慰的结果之一，就是不断开拓新的、更广阔的前景。

——尼古拉·特斯拉

为了充分理解Docker Swarm带来的挑战和好处，我们需要从头开始讲。我们得重回代码库并决定如何构建、测试、运行、更新和监视正在开发的服务。尽管目标是在Swarm集群上实现持续部署，但我们得先退一步去研究持续集成（Continuous Integration，CI）。为CI流程定义的步骤将决定我们如何继续实施持续交付（Continuous Delivery，CD），继而实施持续部署（Continuous Deployment，CDP），并最终决定如何确保服务被监控并能够自愈。本章探讨的持续集成是更高级过程的先决条件。

给《微服务运维实战（第一卷）》读者的提示

这一页的内容与已经出版的《微服务运维实战（第一卷）》的内容大致相同。如果你对这部分内容印象依旧深刻，请直接跳到第1.1节。写第二卷时，我发现了一些更好的方法来实现CI过程。希望你能从本章的内容中获益。

要了解持续部署，首先应该定义它的前身，即持续集成和持续交付。(www.xing528.com)

项目开发的集成阶段往往是软件开发生命周期（Software Development Life Cycle，SDLC）中最痛苦的阶段之一。各个团队要花费数周、数月甚至数年独立开发不同的应用程序和服务。每个团队都有自己的任务。尽管定期单独验证这些应用程序和服务并不困难，但是当领导决定把它们集成到一起时，我们还是会忧心忡忡。凭借以往的经验，我们知道集成会出问题（未满足的依赖关系、不能正确通信的接口等）。这个阶段往往要花费几周甚至几个月的时间。更糟糕的是，在集成阶段发现的错误意味着要回过头来重做几天或几周的工作。如果有人问我对当时集成的感觉如何，我会说糟透了。

后来，极限编程（eXtreme Programming，XP）的各种实践应运而生，自动化测试变得频繁，持续集成开始起步。今天我们知道以前的开发方式是错误的。软件行业已经发生了很大的变化。

持续集成是指在开发环境中集成、构建和测试代码。它要求开发人员频繁将代码集成到共享代码库中。集成的频率取决于团队的规模、项目的规模以及开发时间。大多数情况下，程序员要么直接推送到共享代码库，要么将代码合并。无论是推送还是合并，这些操作一天至少应该进行几次。让代码进入共享代码库中还不够，我们还需要一条流水线，它能检出代码并直接或间接地运行测试。如果流水线执行失败了，应该通知提交代码的人。

持续集成流水线应该在每次提交或推送时运行。与持续交付不同，持续集成没有明确定义该流水线的目标。我们不知道还需要做多少工作才能把代码交付到生产环境，只能尽量做到让提交的代码通过现有测试。尽管很难实施，但CI仍是一个巨大的进步。一旦大家适应了这个流程，结果往往出奇的好。

集成测试需要提前提交，或者与代码一起提交。为了获得最好效果，应该采用测试驱动开发（TDD）方式编写测试代码^[1]。

最重要的CI原则是，当流水线失败时，解决问题比其他任务具有更高的优先级。如果不及时解决问题，那么流水线的下一次执行也将失败。长此以往，人们会慢慢忽视失败通知，CI也就失去了意义。越早解决问题越好。