基于DevOps能力模型的持续集成方法

董 昕，郭 勇，王 杰

(1.成都工业学院 计算机工程学院，四川 成都 611730；2.摩托罗拉系统(中国)有限公司成都分公司，四川 成都 611731；3.中国电子科技集团第29研究所，四川 成都 610036)

0 引 言

近年来，软件的规模越来越大，复杂度也越来越高。较大规模和较高复杂度使集成变成了一件困难的事情，软件项目团队极可能会遇到下面的一些问题：

(1)研发人员要等很长时间才能看到自己提交的结果。如果研发人员严格遵守“频繁提交”原则，则上百人的大型研发团队将一直处于提交状态，使集成服务器始终繁忙，某位研发人员必须等待其它研发人员提交的构建通过后，才能知道自己的提交是否构建成功、是否测试通过。

(2)一旦构建失败，研发人员将花费较长时间才知道这次失败是否与自己提交的改动相关。

(3)测试人员不知道在哪里拿对应的构建来进行测试。

(4)项目经理不确定测试人员是否在正确的运行环境上运行了正确的版本等。因此找到一种高效的等解决上述问题的持续集成方法就成了当务之急。

文献[1]提出可将代码静态分析工具Klocwork引入到持续集成系统中提高代码质量，但项目实践发现Klocwork并不适合处理快节奏大代码库的持续集成系统。文献[2]提出使用开源的托管平台GitHub提高版本控制效率，但其只支持Git作为唯一的版本库格式进行托管。文献[3]提出利用NUnit单元测试框架实现自动化单元测试。上述文献基于特定集成环境提出了某些方面问题的解决方案，但是没有从系统层次解决大型软件项目持续集成的根本问题。

本文在上述文献研究及项目实践基础上，提出了基于DevOps能力模型的大规模持续集成方法，该方法从自动化、质量保障及可视化3个维度出发，通过自动化使软件构建、测试、发布整个流程更加频繁、快捷及可靠，通过可视化使项目各项数据形象直观，加强软件开发人员、质量保障人员和运营维护人员的沟通合作。

1 RM项目持续集成系统

作为一种重要的软件开发实践，持续集成要求团队研发成员频繁集成其工作，通常要求每个成员每天至少完成一次集成。每一次集成都必须通过自动化构建(包含编译、发布、自动化测试)验证，使得集成错误及早被发现[2]。本文给出了一种基于DevOps能力模型的以团队基础服务器(team foundation sever，TFS)为核心的持续集成的方法，并在数字集群通信系统对讲机管理软件(radio management，RM)开发项目中应用并得到了验证。

数字集群通信系统广泛应用于公共安全、交通运输、能源和物流等领域。作为数字集群通信系统的手持设备，对讲机为无线用户提供语音和数据服务，在各行各业的指挥调度中发挥了重要作用。对讲机管理系统(Radio Mana-gement，RM)为对讲机用户提供了计算机和对讲机之间的编程接口。RM允许客户修改对讲机配置文件，使客户能够轻松地管理和更新对讲机的软件。该项目有下面几个特点：

(1)项目团队比较分散，除了中国之外，欧洲和美国也有部分开发人员；

(2)项目规模较大，有超过100人参与其中，代码行数达到近百万行；

(3)项目关系复杂，影响面较广，涉及到固件(firmware)、多条产品线、软件遗留系统的重用和架构的重构。

(4)也是最重要的一点，在采用DevOps能力模型方法之前，RM项目几乎没有自动化构建、测试及版本控制技术，编码、构建、集成、测试、交付等还处于各自为政的状态，没有打通整个项目链条。

RM系统需要支持及兼容数款主流对讲机型号，而且未采用持续集成方法，一个主版本通常需要约一百名工程师历时近一年时间开发测试交付完成，效率较低。

1.1 常用的持续集成平台

软件开发生命周期过程随着时间的推移而演变。开发团队意识到定期构建的重要性，开始了每周构建。然后，当每日构建开始时，构建变得越来越频繁，甚至出现了每小时构建。由于频繁构建的好处变得更加明显，团队需要更多的构建。这是因为软件开发的持续集成使软件团队获得正式、可靠的构建。因此，高效持续集成的关键实践为以下几点：只需要维护一个统一的源码库；支持自动化构建；自行测试每次构建[3]；每位研发人员每天都必须将代码提交到主线上；每次提交后主线必须在集成服务器上被重新构建；确保构建快速便捷；测试在模拟环境中进行[4]；每位研发人员都能容易得到最新的可执行文件；每位研发人员都能观察到进度；部署自动化等[5]。由于开发人员和测试人员进行持续的同步工作，要求他们互相之间要不断地更新和反馈消息，了解软件质量的实时状况和快速地修复缺陷[6]。基于这点，持续集成的自动化将发挥巨大的作用。

现阶段持续集成自动化平台较多，比如CruiseControl、Jenkins和Integrity等，百花齐放，各有千秋[7]。本文提出的基于DevOps能力模型持续集成新方法以微软应用程序生命周期管理服务器团队基础服务器即team foundation server(TFS)为核心，提供源代码管理、报告、需求管理、项目管理、自动构建、实验室管理、测试和发布管理等功能，覆盖了整个应用程序生命周期，将在第二章详细介绍该新方法的特点。

1.2 基于DevOps能力模型的持续集成

DevOps能力模型如图1所示包含了3个部分：开发、测试和运维，它是三者的交集。DevOps能力模型的目的是通过高度自动化工具与流程，实现更好地优化软件开发(development，Dev)、测试(quality assurance，QA)、运维(operations，Ops)流程，开发运维一体化，使软件构建、测试、发布、运营、维护乃至整个生命周期管理更加快捷、频繁和可靠。

图1 DevOps能力模型

DevOps能力模型有以下几点优势：

(1)代码的提交直接触发构建及测试：消除等待时间，快速反馈软件质量；

(2)每个变化对应一个交付管道：使问题定位和调试变得简单；

(3)开发流程全程高效自动化：稳定、快速、可预测交付结果；

(4)自动化回归测试持续进行：提高软件交付质量；

(5)软硬件设施和资源共享并按需提供分配：资源利用率最大化。

该模型聚焦于在一个大型组织内实施持续集成必须遵循自动化、质量保证、可视化、持续交付、技术运营、组织文化等方面所需要的能力，有的放矢地解决前面提到的各种问题并持续改进符合企业特点的持续集成系统。可以从中选取3～4点，作为能力模型的维度，并在每个维度上深化，持续改进使能力提升。该模型可根据相应得分而分级(L1-L5，L1为最低级入门级，L5为最高级极致级)，如表1所示。表中CI能力得分满分为100，分3个维度打分，分别是自动化、质量保障和可视化，各项满分为35、35和30分。总分低于20分即为L0无序级，不低于20分但低于40分即为L1入门级，不低于40分但低于60分即为L2进阶级，不低于60分但低于80分即为L3高阶级，不低于80分但低于90分即为L4精通级，不低于90分但低于100分即为L5极致级。

表1 DevOps能力模型

文中持续集成方法的实施和改进会紧扣DevOps能力模型的这些维度来描写：自动化、质量保障及测试、可视化，从这3个维度分别详细阐述基于DevOps能力模型的持续集成新方法的特点及其在RM项目中的具体应用及成效。

2 RM项目持续集成模型的3个维度

2.1 自动化

DevOps能力模型中第一个维度是自动化，其中最重要的是如何实现自动化开发及构建(Dev)。如何减少编译时间？如何增加每天的集成次数和编译次数？如何创建一个稳定的可以随时发布的应用程序代码库？如何实现自动化集成并且自动回滚有缺陷的代码？为了回答这些问题，RM项目找到的解决方案是基于DevOps能力模型的自动化构建系统。图2显示了RM项目的构建系统的拓扑结构。图中构建控制器(build controller)存储和管理一个或多个构建代理的服务。它将处理器密集型工作(如编译代码或运行测试)分发到池中的各个构建代理进行处理。构建控制器处理工作流，通常执行大多数轻量级工作，例如确定构建的名称，在版本控制中创建标签，记录注释以及报告构建状态。因为构建控制器通常不需要大量的处理器时间，所以虚拟机通常足以用作构建控制器的平台。每个构建代理(build agent)专用于单个构建控制器并由其控制。构建代理的工作包括从版本控制库中获得文件、签入文件、编译源代码及测试。当组装一个构建系统时，可以从几个代理开始。然后可在添加团队成员时添加更多构建代理，随着代码库的增长和构建系统的工作增加，进行构建系统扩展[8]。TFS构建系统的核心就在于构建定义与其工作流程。构建定义描述了构建的过程，包括编译哪些代码项目的指令，什么样的行动触发构建，运行什么测试，以及许多其它的选择。构建定义有一系列的定义需要填，就像一个代码项目的属性页[9]。

TFS构建系统的另一个独创性在于构建工作流程(build workflow)。构建工作流程定义具体的构建过程，比如给出编译哪些代码项目的指令、什么事件应该触发构建以及运行什么测试。本质上工作流程就是定义团队基础构建(team foundation build，TFBuild)的构建代码、运行测试并运行其它程序如脚本的方式的XAML文件。每个构建定义都有一个对应的工作流程文件如图3所示。使用TFBuild还可以创建和管理自动编译和测试应用程序并执行其它重要功能的构建过程，并使用构建系统来支持持续集成的策略，或者进行更严格的质量检查，以防止质量差的代码“打破构建”。

图2 RM项目TFS构建系统的拓扑结构

2.2 质量保障及测试(QA)

DevOps能力模型中第二个维度是质量保障及测试。为了在任何时间点都可以向客户交付可运行高品质的软件产品，需要建立持续集成和自动化测试配合的机制。集成和测试的整合，意味着代码在合成到主干前，系统就可以捕获新代码的编译错误或功能错误，并触发代码自动回滚，這是一套动态并且强大高效机制。

RM自动化测试平台是以团队基础服务器(team foundation server，TFS)为核心搭建起来的，实现了用测试分组和并行化降低测试周期、测试集合管理、测试环境管理：自动部署到测试实验室及不同级别测试：封闭签入测试(gated test)、签入后测试(post test)、用户界面自动化测试(UI automation test)等。封闭签入测试是其中具有独创性的测试方法。图4显示了封闭签入的具体过程。当工程师提交代码修改时，快速持续集成被触发。如果编译或封闭签入测试失败，将阻止代码签入，并将代码回滚到测试通过的版本，系统还将自动触发邮件告知机制，将编译或封闭签入测试错误信息通过邮件发送给提交代码的工程师；如果通过编译和封闭签入测试，代码将被签入。封闭签入过程提高代码的质量，而且避免了无意义的重复劳动和人工操作可能存在的潜在错误。代码签入后，签入后测试将被触发，测试报告将发送给提交者[10]。并且在夜间12点运行涉及范围更广、测试用例更多的自动化测试。

图4 封闭签入流程

如图5所示，在RM测试框架中TFS负责安排自动化测试、实验室部署和测试结果收集等一系列活动。测试框架中主要组件如下：测试管理器(test manager)、测试控制器(test controller)、测试代理(test agent)及实验室管理器(lab manager)。测试管理器主要功能是为软件测试人员和测试主管提供一个专用于管理和执行测试计划的工具，将测试计划、测试集合和测试用例存储于TFS中。它负责配置测试控制器，测试控制器负责配置测试代理并安排一个或多个测试代理以便执行自动化测试。测试运行完后，测试控制器收集测试代理的测试结果数据。TFS保存这些数据便于生成测试报表。测试代理(Test Agent)是作为实验室环境的一部分的工作站，实际测试由测试控制器控制并在测试代理上运行。事实上测试管理器充当TFS客户端界面来驱动自动化测试，这意味着在测试管理器运行测试计划之前，必须正确设置TFS，测试控制器和测试代理。实验室管理器主要用于生成标准测试环境使测试代理能顺利部署构建运行自动化测试。

图5 RM测试框架

RM项目基于TFS搭建了自动化测试平台，其工作流程共有7步：①确定测试环境，即多台计算机的集合，其中每台计算机都有特定的功能，软件在环境上部署及执行测试；②创建测试配置，测试管理器利用测试配置定义不同的测试场景；③创建或导入测试用例，测试用例由工作项标识：手动创建测试用例工作项，并将它们与测试方法相关联或者使用tcm命令从测试程序集(DLL)自动生成测试用例工作项；测试管理器可以通过测试中心跟踪查询功能，搜索存在的测试用例；④创建测试计划，创建由查询生成的多个测试用例组成的测试套件；⑤在测试管理器上运行自动化，确保选择正确的选项：正确的构建包含测试程序集及其依赖项、测试运行环境及要使用的测试设置；⑥构建完成后触发自动测试，新构建完成后，可以在“进程”选项卡中指定如何根据默认工作流模板执行自动化测试；⑦得到可视化的测试结果，如图6所示。图中显示测试结果的概况，比如基于某些功能模块的测试集合的通过率和总的测试用例通过率等测试数据，可为进一步测试、持续集成及质量改进提供重要依据。一旦测试失败，一方面记录会自动发送给代码提交者和测试负责人，缺陷会被及时记录及修复；另一方面快速定位到哪次提交的代码影响了主干代码的稳定性，并可以使代码快速回滚到上一个的稳定版本。

图6 自动化测试结果

该方法不仅支持回归测试的全自动化，而且测试周期的大幅减小，实现了测试环境准备、测试用例执行的自动化，提高了测试效率。

2.3 可视化

DevOps能力模型中第3个维度是可视化。持续集成和改进需要依靠数据全面反映DevOps状态的数据，并且可视化贯穿持续集成的全过程，因此需要建设可视化的能力。基于DevOps能力模型的可视化软件的开发吸收了多种先进的开源技术的优点而开发的。而其中，Python Flask是使用Python编写的轻量级Web后端应用框架；MongoDB是基于分布式文件存储的数据库；G2是阿里由纯Javascript编写的语义化图表生成工具；React是脸书公司提供的响应式(Reactive)和组件化(Composable)的视图组件技术；AngularJS是谷歌设计和开发的一套功能全面的前端开发框架；jQuery是一个快速简洁的JavaScript库；Bootstrap是Web样式CSS框架，它为HTML标记语言提供了一种网格式的样式描述方案，直观定义了Web页面元素的显示方式[11]。在这里以质量保障及测试(缺陷数量趋势、缺陷生存周期和失败的测试用例等)和项目完成度中的燃尽图和产品代办项为例，阐述如何进行可视化。

图7就是可视化页面中质量保障及测试的结果。图中左上角表示过去、现在和预测将来的缺陷数量。如果测试运行一段时间之后，缺陷数量趋于稳定或不再增长。这说明测试比较充分，发现了绝大部分的缺陷，预计尚未发现的缺陷较少。相反，如果缺陷持续增加，说明极有可能还有更多的缺陷尚未发现，还需继续测试，项目远未达到交付标准。图中右上角给出了缺陷生存周期和状态等指标，比如在最近7天发现的缺陷有59个已解决，有2个尚未解决，有3个推迟到下个交付解决，没有处于监控状态的缺陷。图中左下角表示最近20天内每天失败的测试用例的趋势，可看出测试用例失败的数量尚未减少，还需继续加大力度分析测试结果，判断是测试用例缺陷还是软件缺陷。图中右下角表示失败的测试用例分布图，反映不同的组件各有多少测试用例失败。测试和开发人员可以判断潜在问题较多的组件集中力量分析。通过这些直观化的信息，团队可以分析软件质量情况，解决缺陷，预测何时能结束测试交付产品。

图7 质量保障及测试可视化

在项目完成度方面，RM项目主要选取燃尽图和产品代办项等来反映项目完成情况。图8左上角是项目某阶段的燃尽图，可看出现阶段的进度领先于计划预期，项目进展较顺利；右上角是现阶段优先级最高的5个产品待办项(product backlog item，PBI)。5个待办项中，有1个工作量较大，占30个人月；3个工作量居中，占13-15个人月，1个工作量较小暂时忽略不计。可看出，优先级最高的5个产品待办项的总工作量为71个人月，整体基本可控，不会带来太大的进度风险。

图8 某项目冲刺进展情况可视化

在引入可视化之前，团队存在的一种典型的反模型是含糊不清的“完成”定义，开发人员迫于时间压力可以侥幸少做一些功能或忽略一些潜在缺陷[12]，引发的功能障碍的例子就是：团队签入了许多功能点，冲刺结束时绝大多数功能点都是“几乎完成”，但都有细小的模块没有实现。这导致产品负责人在软件上市前无法判断还剩余多少工作为真正完成，从而带来了不可预测性、不确定性及未知的质量风险[13]。而自从团队明确定义了项目完成度的关键因素，并以可视化的形式设置了需要认真对待的“完成”标准，开发人员主观或非主观漏掉功能点并导致软件不可上市的情况被消除。

3 持续集成新方法的使用成效

从项目实践可知，基于DevOps能力模型的持续集成新方法能显著缩短构建周期和软件版本控制的时间。如图9所示，Paradise RM 2.3项目使用了该方法后进行软件版本控制的时间从之前未使用该方法的手工集成150分钟缩短到3分钟，效率提升98%；构建周期从之前未使用该方法的平均270分钟缩短到80分钟，效率提升70%。为了验证该方法的成效，将该方法移植到Tetra RM项目，使用了该方法软件版本控制的时间从之前未使用该方法的48分钟缩短到3分钟，效率提升近94%；构建周期从之前未使用该方法的平均109分钟缩短到40分钟，效率提升约63%。由两个项目的实践得到结论，采用DevOps能力模型持续集成新方法使RM项目构建周期和软件版本控制时间显著降低，效率显著提高。

图9 所提方法使用前后构建周期和软件版本控制时间比较

基于下面几个方面的分析，可以得出RM持续集成系统的特点：

(1)性能方面，该方法的每一步都采用了自动化技术，能快速完成。这里将持续集成可分为两类：快速持续集成和全面持续集成。快速持续集成可以实现立等可取(如果不包括可用性测试可以在5分钟内完成)，而且支持封闭签入，如果包括可用性测试可以10分钟内完成。全面持续集成如果不包括测试可以在30分钟内完成。其中测试可以在其它专用测试机上部署和执行，测试时长是变化的，依赖于团队选择测试用例的策略和不同目的的测试类型，还可以通过在多个测试机上分布式运行测试用例来缩短测试周期。

(2)质量保障及测试极大地提高了生产效率和软件质量。如果没有一个稳固和及时反馈的质量系统，持续集成就是一个纸老虎。该方法预先创建好测试用例集合，根据测试目标和功能自动选择测试集合并监控测试是否通过，如果通过将测试结果保存至测试结果库中。如果测试失败，通过自动发送邮件通知和报告等机制，帮助开发人员快速定位问题，找出问题原因，修复问题并通过测试。

(3)该方法还实现了非常有意义和强大的可视化及报告功能，包括：在持续集成构建服务器的启动/关机测量；构建请求和持续集成服务器的响应时间统计[14]；需要注意的突出问题的报警：构建代理的短缺；过于频繁的签入代码导致持续集成资源短缺，能定位到特定的构建和发起者；可能是由于糟糕的设计或编码引起的与之前构建相比太长的周期。RM持续集成最终实现了团队按计划构建，项目按计划运行，质量有保证；能够向个人、团队/项目发起报告。

(4)可用性方面，该方法实现了构建服务器的相互备份，物理位置在不同国家的服务器互为备份，当某台服务器关闭时，另一台支持自动切换。当出现故障服务器恢复正常再次运行时，构建服务器可以自动切换，提高了系统可靠性[15]。

(5)该方法还实现了硬件资源的高效利用：一方面是充分利用了虚拟机，能够在Hyper-V环境中部署复杂的应用程序，支持构建自动化及测试自动化，并且按需动态分配资源；另一方面使24小时全天候运行状态成为现实。

该项目牵涉多条产品线由几个子项目组成，是一个为期3年的产品规划。重建的RM系统对未来的集群通信系统无线终端设备的产品线发展有重大意义。在采用DevOps能力模型方法之前，RM项目几乎没有自动化构建、测试及版本控制技术，编码、构建、集成、测试、交付等还处于各自为政的状态，没有打通这一链条，处于DevOps能力模型的无序级。采用DevOps能力模型方法之后，RM项目有效利用了各项自动化技术，加强了质量保障及测试，实现了数据可视化，发动全体人员建设持续集成系统，构建了一个相对完善的系统，基本达到了DevOps能力模型中的精通级。

项目实践中采用DevOps能力模型方法来实现持续集成，该方法实现了RM自动化生命周期管理，其中包括：封闭签入、编译/构建、静态分析、单元测试、代码混淆、安装包生成、安装包部署、集成测试、黑盒测试和错误报告。通过RM项目实践，验证该方法极大提高了软件发布效率。从2013年至今由于使用该方法使研发成本减少了40%，将原来4个月的迭代周期缩短到1个月，并且实现软件每天可以发布。并且RM项目是一个由跨越5个国家、3大洲和3条产品线的100多位开发人员的团队组成的大规模软件项目。该方法成功完成了对100万行代码、27年历史的对讲机管理系统架构的重构，并且兼容市面上主流对讲机的所有功能，大大减少了软件人工干预程度，较大程度地提高了软件开发集成发布效率。

值得特别指出的是该方法显著地提高了软件质量并降低了项目风险。经过集成测试每个改动签入的问题都会被更早地发现。长时间的集成不再存在，盲区被彻底消除了。在任何时间都知道项目的进展，什么能运转，什么不能运转，系统里有什么明显的问题，这些都一目了然。持续集成不能防止问题的产生，但明显简化定位和修复问题工作。由此可见，该方法使软件开发工作更便捷，在软件开发生命周期中的每个环节都能获得可部署的软件，并且能及早发现缺陷，缩短了开发时间，降低了软件研发成本。通过该方法，软件研发团队可以降低风险及减少重复性劳动，使得整个研发团队能更好地掌握项目的状态，在资源有限的情况下按时地保质保量地顺利完成项目。

通过项目实践，可看出基于DevOps能力模型持续集成方法具备下列这些优点：①当开发、测试及运维人员处于分布式开发环境中，持续集成是一种很好的方式确保开发人员正在构建的构建是最新的；②连续集成能减少回归次数；③开发人员能尽早捕获构建中断，不必等待一天或一周的结束才了解某个签入对构建的影响；④在软件生命周期中集成测试提前进行，每次签入都要进行集成测试，尽早发现问题；⑤持续集成能实现更好的开发过程，每个开发者都要对构建负责，而且总是有一个最新最好的构建，用于演示和展示等。当然，该方法也有一些不足之处，比如：持续集成会增加维护开销；需要开发人员改变心态；签入直接导致代码备份，因为程序员无法签入部分完成的代码等。

为了更好地阐述本文新方法的优势，将该方法与传统方法进行对比分析。由于Jenkins方法在业界使用最广泛，最具有代表性，因此将该方法与Jenkins方法从3个方面做了对比分析，结果见表2。从表2的几个方面比较可见，基于DevOps能力模型持续集成方法与现有较常用的持续集成平台Jenkins比较，前者具有以下一些优点：插件实用性较高，界面友好，清爽简洁，代码构建支持更换代理，构建流程较清晰。但是也有一些不足比如插件不够丰富，后期可以丰富其插件库，来进一步提升该方法的优越性。

表2 本文方法与Jenkins方法比较

4 结束语

综上所述，该持续集成方法提出了DevOps能力模型，并且从自动化、质量保障及可视化等维度出发，实现了多个产品且每个产品多版本的软件开发、测试及运维的高效融合，提高了开发效率，降低了项目质量风险。实践结果表明，该方法值得在其它大规模软件开发项目中推广和部署。在今后的研发项目中，团队前进的方向为实现产品随时可发布，努力做到极致级别的持续集成。