软件学报  2019, Vol. 30 Issue (10): 3056-3070   PDF    
自动化工具对中国DevOps实践的影响
黄璜1 , 张贺1,2 , 邵栋1,2     
1. 南京大学 软件学院, 江苏 南京 210093;
2. 计算机软件新技术国家重点实验室(南京大学), 江苏 南京 210023
摘要: DevOps作为一次软件工程领域的变革,近10年迅速发展的原因是多方面的.关注了中国DevOps的发展历程中自动化工具带来的实际影响以及自动化工具产生的一系列问题.使用系统化文献评价获取了目前DevOps实践中被研究者分析最多的自动化支持工具,从50篇文献中识别出包括Docker、Chef、Jenkins和Puppet等69个自动化工具;然后通过灰色文献评价从一些中文博客文章中分析出自动化工具在中国DevOps实践中出现的3个层次的问题;最后通过民族志访谈方法分析了在中国环境下各方对待3个层次问题的看法和建议,得出自动化工具对中国DevOps实践的两个影响:(1)自动化工具在DevOps实践的前期作用明显,可以认为DevOps实践就是使用自动化工具;(2)软件组织实现DevOps转型以后需要减少对自动化工具的依赖,形成自己的DevOps文化.对于自动化工具在中国DevOps实践中产生的问题,整合访谈内容后形成了解决问题的3个建议,并给出了一个转型范例.
关键词: DevOps    自动化工具    经验研究    民族志    访谈    
Practical Impacts of Automation Tools in Support of DevOps in China
HUANG Huang1 , ZHANG He1,2 , SHAO Dong1,2     
1. Software Institute, Nanjing University, Nanjing 210093, China;
2. State Key Laboratory for Novel Software Technology(Nanjing University), Nanjing 210023, China
Abstract: As a revolution in software engineering, there are many reasons for the rapid development of DevOps in the past ten years. This study focuses on the practical impact of automation tools in the Chinese DevOps practice and a series of problems arising from automation tools. Systematic Literature Review (SLR) is used to identify the most popular tools, and finally 69 automation tools are identified from 50 researches, including Docker, Chef, Jenkins, and Puppet. Three levels of problems of automation tools in DevOps are summarized from some Chinese blogs using Gray Literature Review (GRL). Finally, ethnographic interview is used to analyze the opinions and suggestions from three aspects of DevOps practice in China, obtaining two effects of the automation tools:1) the role of automation tools in the DevOps practice is obvious at the beginning, and DevOps practice is considered using automation tools; 2) software organizations need to reduce the dependence on automation tools and form their own culture of DevOps. To solve the problems of automation tools in Chinese DevOps practice, this paper summarizes three suggestions from the interview and gives a paradigm.
Key words: DevOps    automation tool    empirical study    ethnography    interview    
1 研究背景

社会经济的不断发展使得用户需求的多样性以及市场竞争的激烈性不断增强, 如何快速完成软件的开发运营从而缩短实现软件的商业价值的时间成为所有软件企业组织在应对软件行业发展的挑战时所需要考虑的重要问题.为了应对这个问题, 从21世纪初开始, 敏捷原则和精益方法在软件开发实践中不断得到普及, Scrum和极限编程(extreme programming, 简称XP)是其中最典型的两种方法.而随着敏捷原则在开发中的迅速应用, 面向经验性的传统运维与它的矛盾逐渐加深, 如何解决这一矛盾成为了一个新的研究话题.John和Paul在“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”的演讲中总结了Dev和Ops的不同观点和思维方式, 提出以自动化基础设施与共享版本控制为核心的解决方案, 并阐述了以信任与尊重为核心的早期DevOps文化[1].

然而, DevOps发展了近10年, 至今仍缺乏对其清晰和统一的认知.Andrej等人认为, DevOps是一种组织方法, 强调在软件开发组织中的团队, 特别是开发与运维团队内部或者之间的情感共鸣和跨职能协作, 以此来达到快速交付和响应变化[2].Matej等人认为, DevOps包含了一系列能够缩短软件设计变化的、可控的、可操作的软件工程策略[3].Ramtin等人也对学术界和业界出现的DevOps相关的概念进行了研究[4, 5].因为没有官方定义, 所以每个人都可以根据自己的想法赋予DevOps一个定义, 也就不断地为DevOps增加了新概念、新实践和新工具.

从发展程度上看, Puppet Labs在“2017年DevOps报告”[6]中指出, 高性能的DevOps团队在代码生成量与稳定性方面优于其他团队.由于社会环境对人有巨大的影响[7, 8], DevOps实践在中国环境下会与国际范围内有一定的差异, 南京大学在2018中国DevOps年度报告[9]中提出了准高性能团队的概念, 认为中国在DevOps团队建设方面, 大部分的团队还达不到Puppet Labs所定义的高性能团队的标准, 而且国内的准高性能团队主要进行的是主干开发、版本控制、测试方面的实践, 更多的是使用工具帮助构建开发环境、实现自动化部署和监控软件系统的健康状况, 对于计划、持续集成和持续反馈阶段的工具关注较少.

DevOps是对传统软件开发实践的一场变革, 其中, 自动化处于关键位置.因为短周期的高质量交付需要高度的自动化, 而且快速获取反馈的关键也是自动化; 工具是实现自动化的基础, 在DevOps知识体系的5个层面中(如图 1所示), 工具处于最底层, 是DevOps的基石[10-12], 所以, 对于DevOps实践中的自动化支持工具的研究也在不断地增多.而对于DevOps自动化支持工具的分类已经有了很多成熟的模型, Xebialabs公司提供了DevOps工具周期表, StackOverdrive公司则提供了DevOps工具全景图.在学术界中, Vaasanthi等人提出了基于数据挖掘技术的对DevOps工具进行分类的新方法[13], Kersten则对DevOps自动化支持工具的爆炸性增长问题提出了自己的见解[14], Farcic则对DevOps工具集中的持续集成与持续部署部分保持了关注[15, 16].

Fig. 1 Knowledge system of DevOps 图 1 DevOps知识体系

随着DevOps的不断发展, DevOps观念不断获得认同, 支持DevOps的自动化工具不断增多.虽然DevOps不仅仅只会停留在工具层面, 但是工具之于整个DevOps是不可或缺甚至具有决定性作用的一部分.研究DevOps中的自动化工具, 也会进一步推动DevOps的全面发展.

本文第1节介绍研究背景, 阐述DevOps文化以及DevOps在中国的发展和DevOps与自动化支持工具的关系.第2节介绍研究方法, 阐明3个研究问题以及针对这3个研究问题使用的不同的研究方法和研究过程.第3节对获取到的数据进行定性分析, 通过系统化文献评价获得学术界最关注的一些DevOps自动化支持工具, 通过灰色文献评价获得这些自动化支持工具在实践中存在的3个层次的问题, 最后通过访谈得出企业进行DevOps转型的一个范例以及对DevOps自动化工具的一些建议.第4节对研究的成果和不足进行讨论.第5节对研究进行总结和回顾.

2 研究方法 2.1 研究问题

DevOps倡导的理念需要自动化给予支持, 尤其是在开发和运维方面.认识DevOps自动化支持工具的现状, 理解现有自动化工具在中国环境下DevOps实践中的问题, 能够更好地促进DevOps在中国的发展, 本文提出以下研究问题.

研究问题1:目前DevOps实践中有哪些自动化工具?

该问题旨在收集目前DevOps实践中的自动化工具, 形成一个工具集合, 并为后续研究提供参考.为了回答这个问题, 本文从学术文献中收集证据, 从学术文献中搜索、筛选并统计DevOps实践中的自动化工具.

研究问题2:目前的自动化工具在中国的DevOps实践中存在哪些问题?

该问题旨在找出中国的DevOps实践中自动化工具存在的问题.为了回答这个问题, 本文在学术文献证据的基础上, 从部分中文博客论坛中收集灰色文献, 进而从这些证据中抽取数据进行定性分析.

研究问题3:自动化工具在中国的DevOps实践中存在的问题有哪些解决办法?

该问题旨在给研究问题2中的问题提出解决方案.为了回答这个问题, 本文邀请国内部分DevOps研究者、DevOps企业从业人员和DevOps咨询师进行访谈, 对访谈内容抽取数据后进行定性分析.

2.2 研究方法

DevOps文化诞生于技术社区, 随即广泛地应用到软件企业组织中, 近些年来, 学术界对它的关注也逐渐增强, 但是, 相关的研究并不丰富, 所以, 我们除了需要学术文献, 还需要使用博客等材料辅助分析.本文提出的各研究方法间的关系如图 2所示, 首先, 采用系统化文献评价(systematic literature review, 简称SLR)对目前学术界和工业界都认可的DevOps实践中的自动化工具加以集合, 然后, 通过灰色文献评价(gray literature review, 简称GLR)对上述工具集合进行问题的总结, 归纳出多个自动化工具在DevOps实践中存在的问题, 最后针对这些问题, 采取访谈的形式从企业人员、咨询师、研究者这3个角度获取评价, 从而得出对每个问题的建议.

Fig. 2 Research method 图 2 本文研究方法

2.2.1 系统化文献评价

自2004年Kitchenham等人首次将系统化文献评价(SLR)引入软件工程以来[17], SLR已成为软件工程中一种重要的研究方法[18], 在《DevOps自动化支持工具调研》[19]中, 李杉杉等人对DevOps实践中的自动化支持工具做出了系统化文献评价, 对DevOps自动化支持工具的相关文献进行了检索, 本文按照报告中的字符串((DevOps) in title or keyword or abstract AND (tool*)in full-text)进行了初步的检索, 有168篇文献被确定为相关文献, 其中包括IEEE Xplore的71篇, ACM Digital Library的53篇, SpringerLink的19篇以及ScienceDirect的25篇.由于本文更多关注自动化工具在DevOps实践中的影响, 只需要获取学术界常见的工具集合, 因此, 我们对于文献的选择做出了更加严格的限制, 在标题、摘要和关键字中出现DevOps和Tool相关词汇的文献被筛选出来进行数据抽取.最终, 本文得到了50篇DevOps自动化支持工具的相关文献, 对这50篇文献中提到的工具进行抽取, 得到一个DevOps自动化支持工具的集合.

2.2.2 灰色文献评价

灰色文献是由传统商业或学术出版和分销渠道以外的组织制作的材料和研究.通常情况下, 学术文献中的信息会落后于灰色文献[20], DevOps文化起源于技术社区, 发展于软件开发组织, 学术界在对DevOps的理解上相对来说落后于社区和软件组织, 而且研究者使用工具的频率远低于工业界, 在使用中遇到的问题或困扰必然少于工业界, 因此, 针对DevOps实践中自动化存在的问题, 单纯地从学术文献中获取是不够客观和完整的.本文从文献中识别了69个自动化工具, 而XebiaLabs公司根据工具类型的不同, 把120种DevOps工具分成了15个大类, 由此可见, 灰色文献对研究文献具有极大的补充作用.

因此, 针对研究问题2, 本文采用灰色文献评价的方法, 在选取灰色文献来源时, 我们对比了简书、知乎和Gitbook这3个数据源.其中, Gitbook中的数据均为书籍章节, 不能够体现DevOps实践在中国环境下产生的问题; 知乎作为一个网络问答社区, 存在各种问题与解决问题的方法, 但经过检索我们发现, 知乎中问题和回答的数量级较小, 选其作数据源可能会造成较大的偏差; 简书作为一个原创社区, 其作者涵盖了研究者、咨询师和企业从业人员这3类与DevOps实践中自动化工具密切相关的人群, 简书上超过50万个专题中有像Docker等专门收录相关工具文章的专题, 并且每个专题都有比知乎更多的文献.我们通过简书获取博客, 在保证博客的原创性与质量的同时, 能够更好地获取DevOps在中国实践中产生的问题, 对结果的准确性有着更好的支持.本文对于DevOps实践的几个环节:容器、持续集成、版本管理、编译、配置管理, 从简书中选择其中最热门的专题对其中的博客进行爬取.一共爬取到1 942篇博客.由于简书中的博客没有标签选项, 而且对于关键词的搜索策略为包含其中一个关键词即列入结果列表, 因此, 本文检索了关键词“DevoOps”和“工具”, 并对搜索结果以相关性排序的前50篇博客进行分析, 对博客中提出的问题进行归纳, 结合第1次Web挖掘时产生的统计数据整理问题, 形成DevOps文化中自动化工具所存在的问题列表.

2.2.3 民族志:访谈

民族志是用来揭示在某种文化中支撑社会行为的过程和意义的方法[21-24].在民族志方法中, 访谈是获取数据的重要手段[25-28].相较研究文献和灰色文献而言, 访谈可以通过引导访谈对象进行深度交谈来获取更为可靠、有效并且接近实际的信息[29], 对于DevOps自动化支持工具在使用中的问题, 通过访谈的形式可以更为准确地了解它们在实际情境下的真实情况, 此时获取的有关这些问题的建议或者解决方案, 往往在真实情况下能够更加容易地实现.本文的访谈对象都是对DevOps有一定了解的专家, 在了解他们对DevOps中事物的看法时, 结构的或半结构的访谈是最有价值的.而半结构的访谈比结构的访谈能够获取更多被访谈人员自己的想法, 从而可以形成更加客观的结论, 因此, 本文选取半结构的访谈作为访谈方法.

三角测量是民族志研究的基础, 是民族志研究正确性的关键所在, 可以提高资料质量和成果的精确度[25], 因此, 本文在选取被采访人员时, 从DevOps研究者、DevOps企业从业人员和DevOps咨询师这3个维度进行, 从而保证最终结论的准确性.其中, DevOps研究者来自高校, 有多年的DevOps研究经验; DevOps咨询师来自软件咨询公司, 长期从事DevOps方面的软件咨询工作; DevOps从业人员为各公司的架构师, 对于公司开发运维的方式有一定的认识, 并且也参与过一些DevOps项目的开发.

最终, 本文邀请到7位相关的专家参与访谈, 名单见表 1.

Table 1 List of interviewed experts 表 1 接受访谈的专家

针对3个维度的被访谈人员, 访谈时需要采用不同的访谈问题, 由于希望获得更多的信息, 因此, 问题中需要包含更多普泛的问题, 但是对某些具体的情形, 则需要专门的问题.另外, 封闭式的问题在尝试量化行为模式时是比较有用的, 而开放式的问题允许参与者本人来解析它, 从而可以获得更多信息, 有助于阐释不同人员自己的世界观, 因此, 本文对被访人员采用开放式的问题来进行访谈.

自动化支持工具作为研究的对象在访谈问题中并不需要提及太多, 这样可以获得更多的被访人员在无意识下对自动化支持工具的看法, 从而提升结论的客观性.访谈中的问题不拘泥于表 2所列内容, 因为不同的公司所处的行业不同、环境不同, 不同的咨询师所服务的公司也各有不同, 所以, 对于每一位被访人员, 都需要在了解背景以后, 根据具体的访谈情境做出针对性的修改, 具体的修改内容在结果分析中会列出.DevOps咨询师分布在全国各地, 由于地域和时间的限制, 我们对于这部分专家(E3、E4和E5)采取线上访谈的模式.线上访谈是线上民族志的主要部分, 是这个领域开创性作品采用的方法之一.虽然Bruckman认为“线上访谈价值有限”, 但是他评价的是基于文字的线上访谈, 本文采取电话访谈作为线上访谈的形式, 能够获取更多的细节, 而这种方法在Robert V. Kozinets看来也是可取和可信的[30, 31].

Table 2 Outline of interview questions 表 2 访谈问题大纲

2.2.4 数据整合和分析

为了回答研究问题, 我们采用了定量和定性的数据分析方法.对于研究问题1, 采用统计性的描述去整合我们的数据, 为了方便理解, 使用图表来展示我们的数据.扎根理论[32]被用于对研究问题2的回答, 这样的应用能够逐步发现工具在DevOps实践中产生的问题, 并能据此建立一个问题的集合.而在回答研究问题3时, 我们结合了主题分析[33]和民族志方法中常见的摘要叙述[25]方式, 包含了一些逐字引用, 以说明专家对某几个问题的真实看法.

3 结果分析 3.1 针对研究问题1

图 3所示的柱状图展示了初步检索后的168篇文献(2011年~2018年)的分布情况, 由图 3可以看出, 有关DevOps工具相关的论文从2014年开始激增, 在2014年~2017年间, 每年增长的幅度保持了一个较高水平, 而在2018年有一个急剧下降, 这是因为, 本研究的文献检索工作是在2018年第1季度展开的.

Fig. 3 Study distribution of DevOps tools 图 3 DevOps工具相关文献分布

由此可见, 研究者对DevOps自动化工具相关研究的兴趣是逐年递增的.鉴于研究者对DevOps的相关研究的兴趣也是越来越强, 本文又以DevOps为关键词对4个电子文献库进行了一次检索, 记录下每一年相关研究的数量, 并计算每年与DevOps工具相关的文献所占比例, 从图 3所示的折线图我们可以看出, 从2014年开始, 与自动化工具相关的研究在DevOps相关研究中所占的比例稳定在35%~40%.这显示了在DevOps持续发展的阶段, 研究者始终保持了对自动化工具的热情, 同时这也彰显了自动化工具作为DevOps文化的基石的重要性.

针对DevOps实践中常用的自动化工具, 本文对筛选出的50篇文献进行了数据抽取, 共识别出69个自动化工具, 其中提及率超过10%的工具排名如下文的图 4所示.从图中可以看出, Docker、Chef、Jenkins是DevOps自动化支持工具中最常见、最为研究者所青睐的3个工具, 尤其是Docker和Chef, 几乎每两篇文献就有一篇会提及它们.

Fig. 4 Frequency of automation tools in support of DevOps in studies 图 4 DevOps自动化支持工具文献提及频率

3.2 针对研究问题2

对于爬取到的博客文章, 本文首先对发表的时间进行了一些分析, 从图 5中我们可以看出, 有关DevOps实践的5个关键过程——容器、持续集成、版本管理、编译和配置管理中有关工具的博客数量从2013年至今总体上呈现上升的趋势, 并在2017年达到了顶峰, 而从2017年第4季度开始有小幅回落, 出现这个状况的原因可能是DevOps经过多年发展, 在2017年已经接近成熟, 尤其是在工具使用方面, 面临的问题已经趋于稳定.

Fig. 5 Time distribution of blogs in 5 topics on DevOps in Jianshu 图 5 简书DevOps 5个专题中博客数量的时间分布

对于自动化工具在DevOps实践中存在的问题, 根据对简书博客的分析, 可以将其分为多样性、联系、文化这3个不同维度的问题.

3.2.1 DevOps实践中自动化工具的多样性问题

在研究问题1中, 本文根据文献识别出了69个DevOps自动化支持工具, 而在第2节也提到了XebiaLabs公司根据120个DevOps自动化支持工具制作的DevOps工具周期表, 由此可见, DevOps自动化工具数量庞大.而从第2次Web挖掘的博客中, 本文共识别出162个DevOps自动化支持工具, 包括配置管理、构建、测试、集成、部署等不同类型.众多的工具带来了选择上的问题, 在简书的博客中, 每一篇博客都选取了至少一个不相同的工具来搭建自己的工具链, 同一篇博客也会在某个阶段推荐两个不一样的工具, 比如OneAPM就比较了DevOps配置管理阶段的两个工具Fabric和Ansible在使用时给用户带来的不同的体验.

数量众多的自动化支持工具不仅带来了选择的问题, 有时也会带来对工具的理解问题, 在工具日益增多的情况下, 对于DevOps的后来者需要学习和理解的DevOps知识的广度和深度也越来越大.同样, 对于一个工具来说, 功能也是随着时间而增多的, Nagios的官网显示, 它的各种插件已经达到了4 347种.从表 3我们可以看到, 大部分的DevOps自动化支持工具都有很多的插件, 而复杂的工具会在工作时带来更多复杂的情况, 也会带来更多的问题.另一方面, 随着自动化工具功能的完善, 更多的软件组织会采用更加复杂的方式进行开发, 例如, Docker的兴起鼓励许多组织进行基于微服务架构的开发, 这也增加了DevOps自动化的复杂性.

Table 3 The number of languages and plug-ins used by some automation tools in support of DevOps 表 3 部分DevOps自动化支持工具使用的语言和插件数量

3.2.2 DevOps实践中自动化工具间的联系问题

DevOps众多的自动化工具让人在选择上产生困惑, 但是更重要的一个问题是各个阶段的工具之间的联系问题.在第1节中提到, 相比国外DevOps实践的发展, 中国DevOps文化更加关注于工具的使用, 因此, 打造一个易用的DevOps工具链是每一个软件组织都希望完成的事情.但是, 现阶段多数DevOps工具链其实都不够完善, 目前大部分可用的DevOps工具都是基于碎片点的孤立解决方案, 只能在DevOps工作流的特定阶段完成特定任务.以华为软件开发云为例, 它的自定义流水线是解决不同阶段工具联系的一种方法, 但是与其他工具链一样, 它重点关注于Dev阶段, 对于Ops, 虽有布局, 但是关注并不像Dev那样多, 这也导致在Dev和Ops衔接的时候会出现联系不密切的问题.此外, 对于大部分的软件组织来说, 如何将传统工具和新应用联系起来, 会是另一个棘手的问题.

3.2.3 DevOps实践中有关自动化工具的文化问题

无论是DevOps自动化支持工具的数量问题, 还是各个阶段工具间的联系问题, 归根结底它是DevOps的文化问题.没有合适的文化和适应这种文化的人, 即使拥有再好的工具, 也不会成功地实施DevOps实践.这一点在中国尤为重要, 简书中几乎每一篇有关DevOps工具使用问题的博客都会或多或少地提及其中的文化问题, 他们认为单纯地使用工具没有办法打破团队间的壁垒, 因为每一个团队都希望使用最符合自己需求的工具链, 甚至在同一个团队中, 每个技术人员都有自己偏好使用的工具, 而很多时候他们(技术人员)都自视甚高.

敏捷宣言中提到, 最好的架构、需求和设计出自自组织团队, Hackman给我们提供了一个可以区分团队自组织4个层次的权力矩阵[34](如后文的图 6所示).在中国的环境下, 软件组织中的团队大多是管理者领导型团队和自管理型团队.而在软件组织中, 为了保证各个部门间的协作, 必须使用兼容工具, 不匹配的工具集会产生瓶颈、误解和误导, 进而导致大量的时间被浪费, 而在多个部门需要使用一个DevOps工具链时, 如果存在工具选用上的分歧, 在中国的文化环境下, 从权力矩阵中我们可以发现, 在环境这一部分的选择大多由管理者或者企业组织的领导者决定, 而这样的决定形式很大程度上会导致团队间的信任危机, 从而影响业务效率, 进一步地, 这也违背了我们在第1节中提到的以信任和尊重为核心的DevOps文化的精神.这一点尤其表现在开发人员与运维人员可能产生的冲突上, 开发人员关注的重点是新的功能的实现, 而运维人员关注的重点是已有功能的成功运行, 不同的关注重点在工具链中想要获得的内容是不同的, 想要工具链实现的细节也会是不同的, 在开发人员强势、运维人员弱势的情况下, 软件组织必然会选用开发人员所偏好的工具, 这时候, 开发人员可能会因此担负部分运维任务, 这会更加恶化开发、运维二者的关系, 从而让DevOps名存实亡, 变成一种通过自动化工具和手段构建的标准流程.

Fig. 6 Power matrix 图 6 权力矩阵

3.3 针对研究问题3

在访谈中提及工具的多样性时, 专家们总是会谈起工具的选择、联系等问题, 相较于工具本身, 专家们更关注工具在整个实践中的地位、发挥的作用以及它所带来的影响.专家E5就表示, “每个工具有不同的功能, 我们做的事情就是把工具串起来”.专家E4并不关注DevOps自动化支持工具的问题, 他认为有了优秀的工程师文化, 自然而然地可以解决工具方面带来的任何问题(如图 7所示).

Fig. 7 Part of interview with expert E4 on DevOps tools 图 7 对专家E4有关DevOps工具的访谈片段

这一点是可以被理解的, 在整个DevOps实践中, 不存在完全独立于其他自动化工具的工具, 所以, 对于访谈中的这一部分内容我们也作了进一步的识别:我们认为, 在单独讨论某一个工具时, 如果专家对这个工具进行了延展, 提及了与之有交互的其他工具, 那么这一部分的访谈也会被认为是涉及了工具间的联系问题; 而在单独讨论某一工具时, 如果专家也提及了文化问题, 我们也认为这一部分的访谈可以作为专家对文化问题的回答.

在涉及DevOps实践中自动化工具的多样性问题时, 众多的插件使得工具变得更加复杂这个问题在专家看来是不可避免的, 因为“插件的产生肯定是为了满足某一个需求”.面对这个问题, 专家E7认为, 在选择工具时需要固定一个版本, 不要冒然地改动, 当遇到问题时再根据实际情况选择合适的更新版本.

在面对如何选择自动化工具的问题时, 专家们表示, 适合公司的、团队成员更加熟悉的工具更应该被使用.专家E1就把选择工具类比为选择程序设计语言, 认为在选择工具的时候需要考虑到团队的技术积累.若是某个环节上引入的工具对于团队人员来说不是那么熟悉, 那么专家给出的建议应是从其中选择开源的、参考资料多的以及被使用程度高的工具, 在专家E2看来, “在每个环节都有两三款处于领先地位的工具, 其他的工具其实差很多, 而这些处于领先地位的工具的参考资料都是极大丰富的, 比如说版本控制阶段的Git”(如图 8所示).

Fig. 8 Part of interview with expert E2 on tools selection criteria 图 8 对专家E2关于工具选择标准的访谈片段

专家们表示流水线是解决工具之间联系问题的一个好的选择.而在构建流水线时, 专家E4表示要从持续集成开始, 慢慢地扩展到持续交付, 从而形成一个规范的自动化的流水线.对于流水线的应用, 专家E3则表示应该从平台开始, 技术先行, 然后采用试点的方式, 先对和企业核心资产关系不是太亲密的部分进行改革, 逐渐改善流水线, 最后达到引入DevOps的目的.专家们对于流水线的建议十分契合唯物辩证法中的两点论与重点论, 在构建这样一条DevOps流水线时全面统筹企业的所有部门, 厘清重要功能与在短时间内可深入改革的部分, 从持续集成这个重点开始进行DevOps转型, 最终实现快速响应交付.

在DevOps实践中运维与开发的联系的问题是最重要的部分之一, 大部分专家也表示这是一个很关键但却是比较困难的问题.专家E7认为, 他们公司就没有完全打通开发和运维之间的壁垒, 需要在以后的实践中对持续部署这部分做更多的工作; 专家E4则认为, 目前开发和运维之间联系不密切的原因是技术能力的不足, 他相信, 在基础设施达到某一水平之后, 二者之间的壁垒自然而然就会打通, 而在达到这个水平之前, 开发和运维的工具链仍然是封闭的.本文认为, 二位专家的意见是一致的, 专家E4作为咨询师, 在企业DevOps转型中提供咨询的服务, 但是在基础设施不能够达到要求时, 也会束手无策; 专家E7作为DevOps企业从业人员, 则从实际的工作环境角度对基础设施的问题做出了自己的回答, 并希望可以在某些环节能够有技术上的提升.

在谈到传统工具与新工具的联系问题时, 专家们的分歧较为明显, 专家E1表示, “要尽可能地降低整个学习的成本, 尽可能地迁就项目团队成员原有的一些工具, 然后需要去找新的工具, 那么新的工具要与原有工具的匹配度尽可能地好一些”; 而专家E2则表示, 应该在软件层面上对原有的工具进行全部替换, 他指出, 现有的企业大多数是这样进行的.本文认为, 这是二位DevOps研究人员在思考这样的问题时把自己代入的环境不同所造成的.专家E1长期从事敏捷开发的研究, 思考这类问题时更多考虑的是有着长期敏捷开发经验的组织, 访谈中他也经常提及敏捷在DevOps中的作用与不同, 敏捷团队比起其他传统的团队对于DevOps有更好的适应性, DevOps实践中很多自动化工具我们也可以在敏捷开发中看到; 而专家E2长期从事的是软件开发过程的研究, 更多思考的是传统的软件开发流程, 在短周期交付的情况下, 很多传统的工具已经不能满足需求的快速变更, 与其花费时间匹配工具, 不如直接更换全新的工具链.

在文化层面上, 每一位专家都提到了组织结构和制度问题, 他们提到的康威法则(Conway’s low)认为, “一个组织最终产生的设计等同于组织之内、之间的结构”.而对于具体的企业文化, 专家E1表示要提升团队的自组织性, 对于环境工具的选择要听取更多团队的意见, 探索自组织型团队在中国环境中的优秀实践; 专家E2提出要明确团队目标, 采用能够实现目标的工具与流程, 奖惩应该以实现多少目标为依据, 同时, 程序员要增加自信心; 专家E4则表示, 应该更加相信程序员, 对于工具问题要给予他们更多的选择权力; 专家E7在同意给程序员更多选择空间的同时也认为要通过更多的制度来保证拥有更多权力的程序员不会成为公司的隐患; 专家E3也对这方面做出了自己的总结, “从组织结构上打破部门墙, 从工具的角度使信息透明, 从而做到在工具上可以一次性做到协作, 然后从流程上界定好开发与运维之间的责任关系, 并且能力上要进行多元化的发展”(如图 9所示).

Fig. 9 Part of interview with expert E3 on the relationship between development and operation teams 图 9 对专家E3关于开发运维的关系的访谈片段

综合整个访谈, 我们对各个专家的意见进行了总结, 见表 4.

Table 4 Recommendations for three dimensions of automation tools in support of DevOps 表 4 对DevOps自动化支持工具3个层次问题的建议

对这些建议, 我们可以总结为3点:(1)选择适合组织的、团队成员熟悉的自动化工具, 在此基础上选择开源的、参考资料丰富、被广泛认可的自动化工具, 在适当的时候通过自己开发工具适配组织结构, 自己开发插件满足组织流程对自动化工具的要求.(2)各个阶段选择相互匹配的自动化工具, 加强基础设施的建设来加强工具间的联系, 并以此构建一个标准化的自动化的流水线.(3)构建符合DevOps价值观的企业文化, 变革组织结构, 制定和完善相应的制度, 鼓励程序员, 使之保持信心和热情.

在形成建议的同时我们对访谈中专家对于3个层次问题的关注程度, 从在谈及各个层次问题时的态度、语速、语气以及内容的多少, 形成了表 5.

Table 5 Level of concern with three dimensions of automated tools in support of DevOps 表 5 对DevOps自动化支持工具3个层次问题的关注程度

专家E4在谈到具体工具时语速加快, 而且迅速从具体工具谈到每个工具之间的联系, 再上升为文化, 我们就可以认为, 专家E4对于DevOps自动化支持工具的第1层次问题的关注很少, 甚至不关注, 所以我们把他对多样性问题的关注程度标注为1;专家E1在谈论DevOps自动化支持工具的时候就专注于工具本身, 语气平缓, 语速适中, 并没有表现出对每一种类型的工具有强烈的兴趣, 所以我们认为他对工具多样性的关注程度为3;而专家E6在访谈中大量地介绍他们公司所构建的工具“布加迪”, 语气中充满自豪与自信, 并且坚持认为未来会继续开发这一工具, 则本文认为, 他对于工具本身的关注是很多的, 也很重视工具, 所以我们认为, 他对工具多样性的关注度为5.

表 5中我们可以看出, DevOps的研究者和咨询师对文化问题的关注明显高于企业从业人员, 这在一定程度上也显示了两种不同的思想, 研究者和咨询师更注重企业文化的培育, 认为企业文化决定了更多的东西, 而企业从业人员不会对文化给予过多关注, 他们在乎的是工作是否快捷, 一个工具或者一种实践能否带来效率的提升, 这也符合企业的定位, 任何企业都需要以市场为导向, 而目前的环境中, 能够快速地进行开发和运维则是企业应对市场变化的基础.访谈中, DevOps的研究者也都提到了如今DevOps的研究与工业界存在的差距, 通过表 3我们也可以看到, 这种差距是由于所处的不同的环境造成的, 在某种程度上是不可避免的.研究者对DevOps的研究想要更加深入, 应该要有更细致的规划, 进入企业内部参与企业的每一次转变.而企业也应当重视研究者所给出的意见, 在追求快速、简洁流程的同时, 注重企业文化的培育.

根据各个专家在访谈中的建议、提出的看法以及企业中合适的做法, 对于软件组织引入DevOps, 构建合适的工具链, 本文给出了如图 10所示的自上而下的引入DevOps的范例.软件组织的高层受到DevOps顾问的影响, 学习DevOps的理念, 从而转变自己的思想, 使之适应DevOps的价值观, 然后从制度入手, 把DevOps团队的权力与义务以制度化的形式确定下来, 保证在后续过程中每个环节的责任都能够找到承担的人员或团队, DevOps顾问在制度的起草阶段起到一个建议人的作用.在确定了新的制度以后, 软件组织高层应该对DevOps团队充分地信任, DevOps团队应该在DevOps顾问的指导下, 由原来的Dev团队和Ops团队消除部门墙之后合并而成, 消除部门墙需要有清晰的组织目标, 由DevOps协调各个部门, 向着这个目标协同努力, 与此同时, 改善工作环境, 使每个部门能够更加认同组织.在形成新的DevOps团队之后, 无论是Dev团队成员还是Ops团队成员, 在使用新的流水线和学习使用新的工具时都需要保持自信.而整个DevOps流水线由新合并而成的DevOps团队决定, 原Dev团队和原Ops团队的成员都需要在这一过程中参与或者投票选出DevOps团队使用的工具, 软件组织高层在整个流水线制定中和完成后起到一个监控的作用, 使整个流水线符合软件组织的利益.在制定流水线时应该有先后顺序, 最重要的3个部分是构建、发布和部署, DevOps团队应该从这3个环节入手, 一步步完善整个流水线.

Fig. 10 DevOps paradigm for software organization 图 10 软件组织DevOps转型范例

4 讨论

自动化工具是软件组织中必不可少的部分, DevOps也会是未来软件组织响应快速变化的主要手段, 在引入DevOps的初级阶段, 自动化工具会是最重要的一个环节, 此时可以认为使用自动化工具即为DevOps, 而随着DevOps的发展, 当工具不再成为阻碍时, 软件组织的结构与文化就会超越工具, 成为DevOps发展的新的核心点.可以说, 自动化工具是DevOps发展的基石, DevOps的发展也为自动化工具的发展提供新动力.

在访谈中专家们也对未来DevOps的发展提出了自己的期望, DevOps的研究者们认为, 在技术层面上, 产品的设计、开发和运维会越来越成为一个整体, 且DevOps会成为以后教学中的重点, 越来越多的工具也会出现, 从而推动DevOps的发展; DevOps咨询师们认为, 更多的企业会加入DevOps转型, 不同团队之间的界限会越来越透明; DevOps企业从业者则希望DevOps有一个更细致的切入点, 可让企业更方便、更快捷地提高软件的交付速度.

本文复现了李杉杉等人在《DevOps自动化支持工具调研(技术报告)》中的轻量级的系统化文献评价, 筛选出50篇与DevOps自动化支持工具相关的文献作为数据抽取的原始材料, 但是, 由于DevOps是近10年中才出现和发展的一个概念, 很多DevOps的支持工具也是持续交付所需要的工具, 部分论文可能并不会使用DevOps的概念, 这对我们得出的在学术界关注的DevOps自动化支持工具的排名有一定的影响.我们需要对持续交付的相关文献进行一次检索, 对于其中可能涉及DevOps自动化支持工具的文献, 我们也应该将其归入数据抽取的材料中.

在灰色文献评价部分, 本文从简书上进行了数据的摘取, 在博客数量的统计上, 本文选取简书中最热门的5个DevOps自动化支持工具的专题对其中的博客进行了统计, 这虽然有可能遗漏某些未收录入专题中的博客, 但在横向对比中, 这一点带来的误差是可以忽略的, 收集到的数据仍然可以反映技术论坛对于DevOps自动化支持工具的关注程度.另外, 本文试图探讨DevOps实践在中国的状况, 因此选取了简书作为数据来源, 简书是一个任何人均可在其上进行创作的社区, 用户在简书上面可以方便地创作自己的作品, 互相交流, 它是国内优质原创内容的输出平台, 选取简书可以保证原创性以及专业性, 但是单纯分析一个数据来源可能会带来一些误差, 我们需要其他类似的中文数据来源对通过简书得到的结论加以验证.

由于地理位置的缘故, 本文对部分访谈人员采用电话访谈的方式代替面对面的访谈, 这会带来一定的限制, 在理解被访谈者的真实意图上会存在一些误差.本文的访谈对象中, 两位DevOps研究者来自同一所院校, 两位DevOps咨询师也来自同一家咨询公司, 相同的环境带来的限制会使本文对DevOps理解的广度上有所缩小.解决这一问题的一种方法是在中国环境下寻找典型的DevOps实践, 进入现场观察研究这个实践产生的原因、方式等.在对专家E6进行访谈时, 我们在专家的带领下了解其公司的工作流程, 图 11所示为其公司会议室墙壁上的标语.观察与访谈的结合让我们对他在访谈中提及的一些问题有了更为深入的了解.而这两种方法也是民族志方法中最为重要的方法[25, 28], 二者配合, 就可以实现对一个DevOps实践的更为深入的理解.

Fig. 11 Meeting room of the company expert E6 works for 图 11 专家E6公司的会议室

此外, 对于文中给出的软件组织DevOps转型范例(如图 10所示), 我们需要对其中涉及到的DevOps顾问(咨询师)、软件组织的高层(管理者)、开发团队(Dev)和运维团队(Ops)这4个角色进行回访.因为在不同环境下, 人的行为以及人与人之间的关系是不同的[8], 所以回访有助于了解不同环境中范例的适用性, 以此来进一步完善我们的范例.

5 总结

本文从文献中识别出DevOps自动化支持工具的集合, 根据一些中文博客对DevOps自动化支持工具在实践中出现的实际问题进行了总结, 形成了3个层次的问题, 并对这些问题进行具体的阐述.最后针对3个层次的问题, 采用民族志研究中的访谈作为调研方法, 对7位专家和从业人员进行了半结构式的访谈, 从中归纳出对DevOps自动化支持工具使用的建议.

本文的主要贡献如下.

首先, 我们通过系统化文献评价获得了DevOps实践中常见的自动化工具集合.

然后, 我们通过中文博客总结出在实际的DevOps实践中这些自动化工具产生的问题.多样化问题、联系问题和文化问题这3个方面的问题能够很好地覆盖问题的每一个方面.

第三, 我们通过对DevOps实践中3个维度的专家进行半结构式的访谈来获取他们对于3个方面问题的看法和建议, 这些建议能够从不同的角度为软件组织的DevOps转型提供帮助.我们也从专家们的看法中归纳出自动化工具在实际的DevOps实践中的地位, 我们从组织引入DevOps的时间角度, 把其分为前期和后期, 前期我们认为DevOps实践就是对自动化工具的使用与理解, 而在后期, 软件组织需要通过建立符合DevOps价值观的组织文化来减少对自动化工具的依赖.

最后, 我们建立了一个企业DevOps转型范例, 试图在专家建议的基础上, 为软件组织提供更为明晰的转型方向.

参考文献
[1]
John A, Paul H. 10+ deploys per day:Dev and Ops cooperation at Flickr. In:Proc. of the Web Performance and Operations Conf. Velocity, 2009.
[2]
Dyck A, Penners R, Lichter H. Towards definitions for release engineering and DevOps. In:Proc. of the 3rd IEEE/ACM Int'l Workshop on Release Engineering. IEEE, 2015. 3. https://www.researchgate.net/publication/281005085_Towards_Definitions_for_Release_Engineering_and_DevOps
[3]
Nitto ED, Guerriero M, Tamburri DA. DevOps:Introducing infrastructure-as-code. In:Proc. of the 39th IEEE/ACM Int'l Conf. on Software Engineering Companion (ICSE-C). IEEE Press, 2017. 497-498. http://d.old.wanfangdata.com.cn/Periodical/jsjxtyy201612035
[4]
Breno B. de França N, Jeronimo H, Travassos GH. Characterizing DevOps by hearing multiple voices. In:Proc. of the 30th Brazilian Symp. on Software Engineering. ACM Press, 2016. 53-62. https://www.researchgate.net/publication/308855773_Characterizing_DevOps_by_Hearing_Multiple_Voices
[5]
Jabbari R, Ali NB, Kai P, et al. What is DevOps? A systematic mapping study on definitions and practices. In:Proc. of the Scientific Workshop of XP 2016. ACM Press, 2016. 12. https://www.researchgate.net/publication/308857081_What_is_DevOps_A_Systematic_Mapping_Study_on_Definitions_and_Practices
[6]
Puppet. 2017 State of DevOps Report. London, 2017. https://puppet.com/resources/whitepaper/state-of-devops-report
[7]
Fuing Y. A Short History of Chinese Philosophy. New York: The Free Press, 2017.
[8]
Myers DG. Social Psychology. Beijing: Posts & Telecommunications Press, 2016.
[9]
Nanjing University. 2018 DevOps Report in China. Nanjing, 2018(in Chinese).
[10]
Rong GP, Zhang H, Shao D, et al. DevOps:Principle, Methods and Practices. Beijing: China Machine Press, 2017.
[11]
Ebert C, Gallardo G, Hernantes J, et al. DevOps. IEEE Software, 2016, 33(3): 94-100. [doi:10.1109/MS.2016.68]
[12]
Httermann M. DevOps for Developers. New York: Apress, 2012.
[13]
Vaasanthi R, Prasanna V, Philip S. Analysis of DevOps tools using the traditional data mining techniques. Int'l Journal of Computer Applications, 2017, 161(11): 47-49. [doi:10.5120/ijca2017913319]
[14]
Kersten M. A Cambrian explosion of DevOps tools. IEEE Software, 2018, 35(2): 14-17. [doi:10.1109/MS.2018.1661330]
[15]
Farcic V. The DevOps 2.0 Toolkit. CreateSpace Independent Publishing Platform, 2016. http://cn.bing.com/academic/profile?id=97a6e0f33c922076b305ef1a7fda4039&encoded=0&v=paper_preview&mkt=zh-cn
[16]
Farcic V. The DevOps 2.1 Toolkit. CreateSpace Independent Publishing Platform, 2017.
[17]
Kitchenham BA, Dyba T, Jorgensen M. Evidence-based software engineering. Perspectives on Data Science for Software Engineering, 2004, 22(1): 149-153. http://d.old.wanfangdata.com.cn/NSTLQK/NSTL_QKJJ0232647721/
[18]
Zhang H, Babar MA, Tell P. Identifying relevant studies in software engineering. Information & Software Technology, 2011, 53(6): 625-637. http://cn.bing.com/academic/profile?id=4b7f12183046a1d53c9246fa44feb400&encoded=0&v=paper_preview&mkt=zh-cn
[19]
Li SS, et al. A state report of DevOps tooling. Nanjing, 2018(in Chinese). http://softeng.nju.edu.cn/tech_reports/Tech-Report-devops4tools-2018.pdf
[20]
Garousi V, Felderer M. The need for multivocal literature reviews in software engineering:Complementing systematic literature reviews with grey literature. In:Proc. of the 20th Int'l Conf. on Evaluation and Assessment in Software Engineering. ACM Press, 2016. 26. https://www.researchgate.net/publication/303515568_The_need_for_multivocal_literature_reviews_in_software_engineering_complementing_systematic_literature_reviews_with_grey_literature
[21]
Herbert S. For ethnography. Progress in Human Geography, 2000, 24(4): 550-568. [doi:10.1191/030913200100189102]
[22]
Fetterman DM. Ethnography in educational research:The dynamics of diffusion. Educational Researcher, 1982, 11(3): 17-29. [doi:10.3102/0013189X011003017]
[23]
Clifford J, Marcus GE. Writing Culture: The Poetics and Politics of Ethnography. University of California Press, 1986.
[24]
Ingold T. That's enough about ethnography. HAU:Journal of Ethnographic Theory, 2014, 4(1): 383-395. [doi:10.14318/hau4.1.021]
[25]
Fetterman DM. Ethnography: Step by Step. 3rd ed., Sage Publications, 2009.
[26]
Hammersley M. What is ethnography? Can it survive? Should it. Ethnography and Education, 2018, 13(1): 1-17. http://cn.bing.com/academic/profile?id=7c3039e81acf7b504fc20da361807183&encoded=0&v=paper_preview&mkt=zh-cn
[27]
Hughes JA. Ethnography, plans and software engineering. In:Proc. of the IET Conf. IET, 1995. https://www.researchgate.net/publication/3748385_Ethnography_plans_and_software_engineering
[28]
Hammersley M, Atkinson P. Ethnography:Principles in Practice. Abingdon: Routledge, 2007.
[29]
Rubin HJ, Rubin IS. Qualitative Interviewing:The Art of Hearing Data. Sage Publications, 2011. https://www.researchgate.net/publication/271104580_Qualitative_Interviewing_The_Art_of_Hearing_Data
[30]
Van Maanen J. Tales of the Field:On Writing Ethnography. Chicago: University of Chicago Press, 2011.
[31]
Kozinets RV. Netnography:Doing Ethnographic Research Online. Sage Publications, 2010. http://d.old.wanfangdata.com.cn/Periodical/lyxk201412012
[32]
Stol KJ, Ralph P, Fitzgerald B. Grounded theory in software engineering research:A critical review and guidelines. In:Proc. of the 38th IEEE/ACM Int'l Conf. on Software Engineering (ICSE). IEEE, 2016. 120-131. https://www.researchgate.net/publication/287491381_Grounded_Theory_in_Software_Engineering_Research_A_Critical_Review_and_Guidelines
[33]
Cruzes DS, Dyba T. Recommended steps for thematic synthesis in software engineering. In:Proc. of the Int'l Symp. on Empirical Software Engineering and Measurement. IEEE, 2011. 275-284. https://www.researchgate.net/publication/224266207_Recommended_Steps_for_Thematic_Synthesis_in_Software_Engineering
[34]
Hackman JR. Collaborative Intelligence:Using Teams to Solve Hard Problems. San Francisco:Berrett-Koehler Publishers, 2011. http://www.wanfangdata.com.cn/details/detail.do?_type=perio&id=10.1177/0095327X8301000106
[9]
南京大学.2018 DevOps中国调查报告.南京, 2018.
[10]
荣国平, 张贺, 邵栋, 等. DevOps:原理、方法与实践. 北京: 机械工业出版社, 2017.
[19]
李杉杉, 等.DevOps自动化支持工具调研.南京, 2018. http://softeng.nju.edu.cn/tech_reports/Tech-Report-devops4tools-2018.pdf