DevOps来了,你准备好了吗?

DevOps的出现源于对加强开发和运维的协作与沟通的期望。第一次软件危机爆发后，为了实现按预算准时交付所需功能的软件项目的目标，人们尝试借鉴建筑工程领域的工程方法来解决问题，各种开发方式随之不断涌现。DevOps开发模式早在2008年就已被提出，只是在容器化时代才逐渐被“发扬光大”。图1-1中各个软件开发模式到现在也都是存在的，只不过诸如瀑布模型之类的软件开发模式被使用的频次越来越低。

图1-1软件开发模式的演进

1.1瀑布模型

1970年，Royce提出瀑布模型，把大型软件开发分为分析与编程的多个阶段，每个阶段都有严格的输入和输出标准，文档是各阶段衔接的唯一信息，管理人员可以根据文档对每个阶段的完成情况有更清晰的了解。但对于开发人员，对阶段的严格划分使得编程变成了一种没有创意的机械劳动。另一方面，瀑布模型的每个阶段间隔较长，往往到开发的后期才可以看到软件的模样。并且由于没有迭代和反馈，瀑布模型对变化的客户需求非常不容易适应。

图1-2瀑布模型

1.2螺旋模型

1988年，Barry Boehm提出螺旋模型，将瀑布模型和快速原型模型结合，采用一种周期性的方法进行系统开发，每个周期都包括需求定义、风险分析、工程实现、客户评估四个阶段。其核心在于不断地迭代，每迭代一次，软件开发就前进一个层次，直到得到最终的产品。在每个阶段或经常发生的循环之前，都必须先进行风险评估。使用螺旋模型要求开发人员具备丰富的风险评估经验，同时过多的迭代次数会增加开发成本，延迟提交时间。

图1-3螺旋模型

1.3极限编程

1996年，为了满足加强开发者与用户沟通的需求，Kent Beck提出了极限编程，其特点是先测试再编码，并让用户全程参与软件的开发过程，以保证用户变化的需求及时被接收并修正。快速迭代缩短了版本的发布周期，小版本发布加快了用户沟通反馈的频率。在极限编程中，文档不再重要，因为小版本功能简单，不需要复杂的设计过程，并且因为可以随时添加用户的新需求，所以无需为扩展考虑太多。

图1-4极限编程模型

1.4敏捷开发

2001年，17名软件大师共同发表了“敏捷宣言”，提出了敏捷软件开发应当遵循的十二原则，并将符合敏捷宣言所倡导的价值观且遵循十二原则的方法统称为“敏捷开发方法”。敏捷开发倡导沟通、拥抱变化，强调发挥人的主观能动性，通过快速迭代和增量开发尽早交付有价值的软件。“持续集成”作为敏捷开发的功能实践，强调频繁的自动化构建和测试，减少了质量保障团队的工作量，排除了开发团队和质保团队的沟通障碍，率先被更多的IT组织接受。

图1-5敏捷开发模型

虽然敏捷开发在开发环节的作用效果显著，但同时也给运维环节带来了新的困难，对运维人员来说，稳定压倒一切，敏捷开发引起的频繁改变造成了开发和运维之间矛盾的爆发，那么又如何解决这些矛盾呢？DevOps应运而生。

在了解了软件开发模式的发展历程，本小节我们来详细阐述一下DevOps到底是什么。直到今天，DevOps依旧没有一个统一的定义，每一位从业者、每一个企业都有自己理解的DevOps。它是来自于Development和Operations的组合词，但是其内容不仅仅涉及到这两个领域。从开发到运维，中间还存在测试环节，因此，把DevOps看作开发、技术运营和质量保障（QA）三者的交集可能更为准确。DevOps希望做到的是产品交付过程中IT工具链的打通，通过自动化工具实现高效协作和沟通，帮助各团队完成产品的生命周期管理，从而减少时间损耗，快速、频繁、可靠地构建、测试和发布产品。

图2-1DevOps内容图

我们知道，当一个项目组只有一名成员时，从需求、开发到测试、部署，全部由一人完成，这时该项目组的工作效率是最高的。但在实际开发中，只有一名成员的项目组是不现实的，一个项目通常需要多名成员，甚至多个团队共同完成。有了分工，就会出现不同的角色，而不同的角色间由于职责和目标的不同存在天然的矛盾，比如运维人员追求稳定，而开发人员追求改变，如果两者互不相让，这样的矛盾最终导致的是效率的下降。DevOps的出现正是为了解决这种矛盾，通过敏捷开发、持续集成等方式，帮助研发团队做到在保证质量的前提下提高交付效率。

图2-2是专家总结的DevOps能力图，涵盖了规划（plan）、代码（code）、构建（build）、测试（test）、发布（release）、部署（deploy）、运营（operate）、监控（monitor）等各个环节，形成了一个无穷符号状的能力闭环，良好的闭环可以大大增加整体的产出。

图2-2DevOps能力图

2008年8月，在敏捷大会多伦多站，比利时独立IT咨询师Patrick Debois发表了“将敏捷实践应用于运维领域”的讲话，并于2009年10月在比利时根特组织了首届DevOps Days社区会议，正式启用了“DevOps”这一术语。DevOps是一组集合概念的统称，其原始定义是“运维工程师和开发工程师参与整个服务生命周期（从设计到开发再到生产支持）的一组实践”，倡导运维人员更多的使用与开发人员相同的技术来进行系统运维工作。

DevOps并非一个标准，而是一种IT组织管理的发展趋势，通过多种方式打破IT职能部门之间的隔阂，改变IT组织内部的原有合作模式，提高业务迭代速度。这种发展趋势将会引起IT组织内部原有角色和分工的变化，甚至影响到相关的业务组织。对于不同的IT组织，需要根据其行业特点及企业自身实际状况进行DevOps的管理定制。

在了解了软件开发模式的发展历程以及什么是DevOps之后，本小节将介绍当前比较流行的DevOps架构，包含方法实践以及常用的工具链。

首先从版本控制系统（常称为代码托管工具）讲起，它位于图3-1中的代码仓库这一环节。版本控制系统主要用于存储及追踪文件的修订历史，从而让相关人员能够回溯那些被纳管的对象的任意一次修订。它的本质用途是解决“4个W”，即在什么时间(When)、修改了什么内容(What)、是谁修改的(Who)以及为什么要修改(Why)。常用的代码托管工具有GitHub、GitLab、SVN以及Bitbucket等等。

图3-1流水线总体架构图

在代码提交这一阶段，常常对应着多种分支开发模式，如“主干开发，主干发布”、“主干开发，分支发布”以及“分支开发，主干发布”等等。每种分支发布模式均存在利弊，团队应该根据自身的情况（如人员的规模、软件的规模和平台工具链的成熟度）来进行选择。本文以应用最为广泛的“分支开发，主干发布”为例进行介绍。

图3-2分支管理

目前企业使用较多的CI工具有Jenkins和Travis。Jenkins是开源CICD(Continuous Integration and Continuous Delivery)软件领导者,提供超过1000个插件来支持构建、部署、自动化，具有如下突出特征：

1）作为一个可扩展的自动化服务器，Jenkins提供完善的持续集成和持续交付功能;

2）可以通过网页界面轻松设置和配置，其中包括即时错误检查和内置帮助;

3）通过更新其包含的1000多个插件的方式，Jenkins可覆盖持续集成和持续交付工具链中几乎所有的工具；

4）可以通过其插件架构进行扩展，从而为Jenkins可以做的事提供几乎无限的可能性；

5)可以轻松地在多台机器上分配工作，帮助更快速地跨多个平台推动构建、测试和部署。

TravisCI 提供的是持续集成服务(Continuous Integration，简称CI)。它绑定了Github上面的项目，只要有新的代码，就会自动抓取。然后，提供一个运行环境，执行测试，完成构建，还能部署到服务器。由于TravisCI服务器托管在云中,因此无需专用服务器。这使我们能够在不同环境,不同机器,不同操作系统上进行测试。由于Travis只提供企业服务并且不是开源的，因此其使用范围较Jenkins小。本文后面的制品探活流水线实例也以Jenkins作为CI服务器进行展示。

流水线（pipeline）是一套插件，让CI服务器可以实现持续交付管道的落地和实施。在Jenkins中通过定义Jenkinsfile控制流水线，一般有两种方式对其进行编写，分别是声明式和脚本化的流水线语法。流水线中会定义不同的阶段完成不同的任务，具体如图3-3所示。

图3-3流水线细节图

部署环境包含两种情况，一是基于物理机或者虚机的部署，二是基于容器化环境的部署。基于物理机或者虚拟机的部署常用到的工具有Terraform、Ansible、AWX等；基于容器化的应用及环境部署则离不开容器Container(如Docker、CRI-O)、Kubernetes、Helm等这些云计算中必备的技术和工具。

基于上文的理论和方法，结合日常的工作，本小节介绍了制品库功能测试与探活流水线的创建实例。制品库功能测试与探活流水线的创建是DevOps工作模式的组内推广，包含11个功能测试点，全面覆盖制品库中常见的仓库类型，包括Docker、RPM、NPM、Helm、Maven等制品存储仓库。流水线具有设置定时任务，进行快速测试并进行邮件告警通知等功能，并且具有可扩展性，增加更多的测试与探活功能点。

探活流水线代码以及资源文件存储于GitLab，图4-1是存储代码的示例，采用上文提到的“分支开发，主干发布”的工作方式，并坚持如下原则：

1）主干分支的代码尽可能保持可发布的状态；

2）主分支代码及时与功能分支同步；

3）功能分支的生命周期尽可能短；

4）一切以主干代码为准，尽可能不在各功能分支之间合并代码。

图4-1GitLab代码仓库

如图4-2，可以通过设置Webhooks的方式进行流水线的触发，可以设置的触发事件包括推送事件（Push events）、合并事件（Merge request events）以及评论（Comments）等等。以推送事件为例，其含义是指当开发人员推送代码到相关的分支中时会自动触发流水线的运行。每开发一个新的功能，开发人员都需要通过Pipeline的检查，然后再创建Merge Request，并分配给相应的人员进行代码审查，最后可以合并功能分支的代码到主干分支。

图4-2Webhooks 示例图

在Jenkins上可以创建多种类型的流水线，如单分支流水线、多分支流水线、maven项目流水线等等。本小节创建了多分支流水线，该流水线可以根据一个SCM（Source Code Management）仓库中检测到的分支创建一系列流水线，这样功能分支的开发人员，也有相应的权限调试流水线，因此可以增强主干分支代码的质量和稳定性。

图4-3多分支流水线示例

下图是具体的流水线，一条流水线包含多个Stage，每个Stage完成不同的功能。当所有的Stage都是通过的状态时，则这条流水线的状态是通过的，流水线呈现绿色。用Eclipse做过Java单元测试的开发人员都知道一句话“Keep the bar green to keep the code clean”，与此相似，在构建流水线时，我们希望要做到“Keep the pipeline green to keep the CI/CD successful”。

图4-4单条流水线示例

随着云计算的发展，DevOps已经成为了一个主要的焦点，并不断的塑造着软件世界。目前，我行正在进行DevOps体系建设，越来越多的项目开始采用流水线的形式进行部署与交付。在如此浪潮之下，我们不禁要问，DevOps来了，你准备好了吗？

[1] 乔梁.持续交付2.0[M].北京:人民邮电出版社,2019

[2]Gene Kim, Jez Humble, Patrick Debois, 等.DevOps实践指南[M].北京:人民邮电出版社,2018

[3]博客园[EB/OL].https://www.cnblogs.com/anliven/p/9136624.html