快速指南：在DevOps中实现持续交付

【编者的话】时至今日，以几乎相同的步调实现开发与交付已经成为一种必需。本份快速指南将帮助你们弄了解持续交付概念中的那些“良方”与“毒药”。

【烧脑式Kubernetes实战训练营】本次培训理论结合实践，主要包括：Kubernetes架构和资源调度原理、Kubernetes DNS与服务发现、基于Kubernetes和Jenkins的持续部署方案 、Kubernetes网络部署实践、监控、日志、Kubernetes与云原生应用、在CentOS中部署Kubernetes集群、Kubernetes中的容器设计模式、开发Kubernetes原生应用步骤介绍等。

开发人员老是面临着软件发布规模与速度层面的种种压力，而这亦促使其采用各种新型概念和工具。可是，使人困惑的术语混淆了真正的技术和商业利益，特别是考虑到供应商也拥有本身的倾向与诉求。若是您须要的是真正的技术手段而非营销口号，你们每每会发现本身很难为持续构建与交付的实现找到最佳方法。本文将为你们带来与持续交付相关的基础知识，但愿可以为各位带来一点启示。

首先，如下术语适用于同一辈子产流程的不一样部分，而各个部分的自动化程度皆不尽相同。

• **持续集成（Continuous integration）**是指频繁将代码合并至中央储存库中。“频繁”一般具体指一天屡次。每次合并操做都会触发一个自动化的“构建与测试”实例，这一过程也会被称为持续构建。可是不管具体表达如何，持续集成和持续构建都没法直接实现交付和部署方面的工做——其只负责代码层面的管理，而不涉及其它具体事务。

• **持续交付（Continuous delivery）**是指软件交付过程当中的自动化机制，其中包括一部分须要开发人员亲自动手的操做。一般来说，开发人员都会容许和启用自动部署，不过同时也会配合其余一些手动的步骤。

• **持续部署（Continuous deployment）**是指不须要开发人员以手动方式操做的持续交付机制。整个流程皆自动实现，而不须要人为参与。

Marko Anastasov在一篇博文中解释称，利用持续部署，“开发人员的工做一般集中在检查同事们提交的合并请求，并在将其合并到主分支上后即宣告完成。”持续集成/持续部署服务在这里接管后续工做，包括运行一切测试案例并将代码部署到生产环境中，然后通知相关团队每个重要事件的对应结果。

然而，仅仅了解术语和它们的定义并不能帮助你们肯定应在什么时候、何地对其加以运用——毕竟每种技术都拥有着本身的优点与劣势。

固然，若是市场能像对待DevOps同样清楚地区分这些概念、工具及其对应受众，天然能够带来完美的成效。然而……

“DevOps是一种概念，一个想法，一类生活哲学。”软件交付自动化厂商XebiaLabs公司首席营销官Gottfried Sehringer指出。“这并不是一种特定工序或者工具集，也不是一种技术。”

遗憾的是，行业里的术语不多配有简单明了的表述，也没有提示可以告诉人们如何以及什么时候使用这些技术。所以，这份指南旨在帮助你们了解什么时候适合使用哪一种技术。

根据你对速度的需求来选择加速方案

等等，速度难道不是全部软件开发的关键吗？现现在，公司一般都会要求开发人员天天，每周或是每个月进行软件更新或者添加新的功能。这在过去，甚至在敏捷开发时代下都是闻所未闻的严苛要求。

不止于此，一些公司还会追求更快的软件更新速度。Sehringer说：“若是你在亚马逊工做，那极可能每几秒钟就须要进行一次更新。”

不论你是软件漏洞的行家，或是开发人员又或是运维专家，当必须快速完成构建与发布任务时，你们该如何提供高质量且“不破坏任何既有成果”的代码呢？面对这样的问题，每一个人都有本身的妙招。“敏捷开发”，“持续构建”和“持续集成”则是其中呼声最高的三种方案。

下面让咱们对其进行归纳说明。

软件服务供应商Nexient公司资深交付主管Nate Berent-Spillson指出，“你能够把持续性当作是‘自动化’。它下降了开发和部署的成本与时间。”

那为何不直接使用自动化做为专业表达？

自动化概念的加入、持续构建、持续交付以及任何与持续性相关的因素，都属于DevOps的核心范畴，而咱们其实陷入了文字表述的误区。下面，咱们将带你们共同理清思路。

自动化DevOps的三要素

持续构建的本质在于“经过小步骤进行构建。”每一个小的步骤都是为了把软件以持续性方式集成到生产环境中这一目标而服务。

尽管部分实践者会对“持续集成”概念做出进一步细分，但“持续集成”这一标签仍经常被指向同一类事物。持续构建属于持续集成的组成部分：在持续构建的过程当中，开发者只需编写代码，并将其与仓库中现有的代码合并，以后就可让自动化来接管构建和测试合并后的代码。这样开发者将没必要浪费时间在手动编译和测试上，而是把更多时间投入到代码编写与创新实现身上。

可是，仅仅利用部分自动化工具并不意味着可以提高整个发布流程的速度表现。毕竟代码自己尚未部署完成——而部署工做可能须要手动操做，也可能由于开发人员忙不过来而被推迟。

做为OutSystems（面向企业的移动和网页应用的快速交付平台）公司的首席技术布道者，Dan Juengst解释说：“随着持续集成的运用，组织可以从以笨重的总体式应用（monolithic application）为核心的思惟模式升级到一种可以支持并鼓励轻量化且高频度软件更新的方案。”

然而，在更大规模的持续集成过程当中，与其说持续集成是一个独立的步骤，不如将它当作是一种并行的步骤。InfoZen公司首席转型官Susan W.Sparks说：“不一样于仅仅提供了一种可持续且低风险代码部署方案的持续交付机制，持续构建在持续集成当中负责按期合并新代码并实施构建。”

正如Sparks所言：“经过持续集成，你也能够实现持续交付。”固然，前提条件是你们的代码具有可部署性。

另外，你们还须要把创新团队放在首位。前雅虎首席技术官，现任Cybic首席技术官的Mike Kail说：“将DevOps落地的第一步一般就是采用持续集成。这为开发人员提供了更加协调的环境，有利于提升代码质量。”

什么时候使用持续集成vs.应用程序的自动化发布

那么持续集成是否就是应用的自动化发布（ARA）——这两种称为是否表明着同一事物？答案是否认的，正如Sparks所言：“它们是同一框架下的两种不一样组件。”

持续集成的运用集中体如今使用公共源代码库(如GitHub)的应用开发人员上。Sparks说，每当开发人员更新软件时，他们的代码都将被从新整合到整个应用中。换句话说，持续集成工具检查全部的源代码，构建全部成果(例如编译软件)，运行全部的单元测试，同时当即做出结果反馈。

另外一方面，应用的自动化发布是指对集成后的代码进行打包，并在开发结束后将代码自动转移。

Sparks说:“举个例子，开发始于代码。当实现了全部功能并经过了全部测试以后，你就能够利用应用程序自动化发布来将代码包移动到下一个环境，例如测试环境。”

从另外一个角度来看，就像Sehringer说的：“持续集成是内容，而应用的自动化发布则是运用工具的过程，两者属于同一事物的不一样侧面。”

冲洗。重复、重复、重复、重复（DevOps中的自动化）

自动化机制拥有理想的投资回报。Sehringer指出：“若是在前期制做阶段可以确保产品的万无一失，那你就能当即把它推向生产而不破坏任何原有成果，以后只要重复这一过程就能够了。”

换句话说，您能够经过结构化、可重复的自动化方式来实现全部的交付步骤，从而下降风险并提升发布和更新的速度。

“在最理想的状况下，你只需按下一个按钮，就能够作到每几秒钟就进行一次发布。”Sehringer说。“但现实世界没那么理想化，仍是须要人工插手来把整个流程对接起来。”

公司可能须要法务部门的批准才能对应用作修改。Sehringer指出：“一些受到严格监管的公司甚至须要额外的手段来确保合规性。所以，了解瓶颈的具体所在是很重要的。”ARA软件应该提升效率，并确保应用可以按时发布或更新。

Sehringer 还说：“开发人员对持续集成更为熟悉，而应用的自动化发布则属于较新的概念，也所以致使理解程度广泛不高。”

整合，然后加以尝试

首先，要了解你的承诺、风险在哪里以及目标是什么。

Berent-Spillson表示：“持续构建、持续集成和持续交付只能算是基本底限，持续部署才是更为深刻的步骤。”

他补充称:“利用持续部署，您能够承诺在不须要人工参与的状况下来部署每一行新代码，而再也不以人为方式一次性将代码发布出去。当新代码提交到存储库时，其将自动接受构建、集成、测试和暂存（stage）。其中的核心变在于对主线开发做出的承诺。”

这些概念的差别之处表现为自动化程度的区别，但它们都适用于一套更为宏观的开发框架。整个流程能够总结为:首先进行持续集成，然后是持续交付或持续部署。咱们能够把持续部署看做是持续交付的升级版。可是在集成、构建和测试完成以前，不会有任何代码被实际部署——这就是为何咱们要将持续集成放在首位。

专家们对于把这些概念付诸实践的最佳建议是从小处着手，而后在每一次迭代中做出小范围改进。最终，你们将再也不专一于单个问题，而是构建起一套可以经过自动化机制实现速度与安全性保障的架构。

Berent-Spillson的建议是，“从持续构建开始，而后提交给自动化测试（测试金字塔），并开始进行持续集成。随着你对持续集成的效果愈发满意，同时不断改进你的自动化部署方案，最终须要确保回滚的无缝化实现能力。”

他解释称，由于回滚难度有所降低，这种方法将使得持续部署变得更容易。“在遇到错误的时候，你们能够进行回滚，而后问本身，‘咱们可以如何利用自动化、感知化或测试手段来防止这一问题的发生?’”

给领导者们的经验教训

• 若是您所作的只是持续构建和持续集成，那么您颇有可能会形成瓶颈并减缓整个部署过程。咱们的目标是实现频繁发布，这意味着您须要更高水平的自动化机制以更快地进行版本发布。
• 在每次迭代中进行部分自动化或改进，直到您最终达到全面自动化。你们能够列出一张清单或一张图表，从而确保至关努力能帮助自身朝着目标稳步前进。
• 在持续集成以后，使用持续交付。只有在解决了持续交付中的合规性与管理问题、而且可以实现无缝回滚以后，您才能够进一步尝试持续部署。持续部署应是软件发布当中人为介入程度最低的自动化阶段。

原文连接：The quickie guide to continuous delivery in DevOps （翻译：马申君）

=========================================== 译者介绍 马申君，代尔夫特理工大学计算机专业的研究生，研究方向是云资源的弹性伸缩和workflow的调度。