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也就失去了意义。越早解决问题越好。
免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。