DevOps中国调查研究

DevOps已提出近十年,其作为敏捷方法在完整的软件生命周期上的延伸,旨在从文化、自动化、标准化、架构以及工具支持等方面,打破开发与运维之间的壁垒,重塑软件过程,以实现在保证高质量的前提下,缩短从代码提交到产品上线之间的周期.在竞争日益激烈的市场环境下,用户对于产品服务的稳定性以及更新频率和效率的要求不断提高,DevOps在学术界和工业界的关注程度因此也不断提高.Puppet Labs在2013年开始了全球DevOps现状的问卷调查,迄今已发布了5份报告.国内DevOps的发展相对滞后,对于国内DevOps现状的研究在工业界和学术界均处于空白.2016年和2018年分别进行了两次关于DevOps国内现状的问卷调查以填补这一空白,两次调查的受访人数分别为74和66人.基于两次调查结果,从DevOps涵盖的IT性能表现、组织文化及相关实践、开发与运维实践、工具支持、领导力、工作比例、员工敬业度及满意度这8个方面,综合分析了DevOps在国内的发展现状与趋势,并与Puppet Labs报告的全球现状进行了对比.总体而言,国内DevOps虽呈现了稳步发展的态势,但与国际水平相比尚存在明显差距,目前能达到国际高水平IT性能的受访团队仅6%.通过对比,总结了17条发现,经过综合分析,获得了3个主要结论：（1）员工素质和人才紧缺是国内DevOps滞后、过程成熟度不高的症结;（2）DevOps化越成熟,员工敬业度和满意度越高;（3）Scrum敏捷开发和基于主干开发是最普遍采纳的实践.基于分析结果,在未来实践与研究上给出了多项建议.     

面向云服务的DevOps知识获取与应用

DevOps作为一种新兴范型能够实现开发和IT运维之间的高度协同,从而在完成高频率部署的同时,提高生产环境的可靠性、稳定性、弹性和安全性.DevOps与云计算一起能够实现资源的按需供给.DevOps制品和云服务的规模不断增长,大量的DevOps知识分散在不同的社区和来源中,没有得到有效的组织、管理和使用,如何针对大量可选的DevOps方法和工具进行有效的决策和选择成为亟待解决的问题.针对这一问题,提出了一套完整的DevOps知识管理方法.方法首先针对一组可访问的知识源进行多种方式的知识获取、组织、转换和存储;然后提出了DevOps知识分类方法,并设计实现了DevOps知识库原型系统;最后基于谓词逻辑提出了DevOps需求的描述方法,并展示了基于需求的DevOps知识库的使用.     

面向完整价值交付的文档DevOps应用研究

随着DevOps在各大软件企业中的广泛实施，加速了系统软件类产品的版本交付和部署.中兴通讯在实施过程中，发现产品重要的组成部分——产品文档，还采用传统研发方式，缺乏配套流程和工具，导致产品文档交付的节奏无法与软件版本匹配，严重影响了产品完整交付的及时性.文档DevOps是一种针对产品文档持续交付的模式.通过分析开源和DITA的文档交付解决方案，同时结合系统软件的研发特点，总结出一套适合系统软件的文档交付综合解决方案，它借助DevOps理念，基于业界的DevOps工具链，构建了"文档DevOps平台"（以下简称iDoc平台），实现面向用户各类文档交付的解决方案，其典型特征有：与软件迭代流程融合，信息单元同源引用，多格式内容源的管理，持续集成的质量守护.在实际企业中通过文档DevOps实现了产品文档与软件版本的同步交付，极大地促进了文档的准确性、完整性和交付效率的提升.iDoc平台已在50多个软件产品中得到成功应用.文档DevOps解决的问题具有普遍性，有助于在更大范围内帮助其他系统软件实现敏捷价值交付，并且，文档DevOps还是对DevOps的一个补充，扩展了业界的DevOps的适用范围：交付对象涵盖了产品文档，流程延伸到市场规划，协同人员覆盖面更广.     

DevOps建设研究和实践

随着信息技术的飞速发展和软件研发框架的不断升级,传统研发中开发、运维、QA之间的沟通协作愈加困难.DevOps作为新软件研发管理理念,其通过促进开发、运维、QA协同工作的模式,得到了越来越多IT企业的关注和使用.文章基于DevOps理念,对其在需求管理、研发过程、运维管理三个阶段的技术路线进行研究,并通过JIRA、Jenkins、Zabbix等工具将DevOps系统落地.在具体项目实践中,保障了项目研发进度,提升了系统健壮性,实现公司产品研发的提质增效.     

一种智能合约微服务化框架

区块链具有分布式、不可篡改、去中心化、历史可追溯等特点,但难以落地.智能合约的引入,有效地解决了这一难题.然而,智能合约的开发和运维存在部署效率低、监控工具不成熟等问题.受DevOps自动化工具支持微服务持续交付、持续监控的启发,针对上述问题,提出了一种用于智能合约微服务化改造的框架.随后,结合支持DevOps的工具设计原型平台Mictract,完成智能合约的部署和监控.在Hyperledger Fabric官方链码Marbles上的案例研究表明,该框架和原型平台能够显著提升智能合约部署和监控的自动化水平.     

软件开发活动数据的数据质量问题

问题追踪系统和版本控制系统等软件开发支持工具已被广泛应用于开源和商业软件的开发中,产生了大量的数据,即软件开发活动数据.软件开发活动数据被广泛应用于科学研究和开发实践,为智能化开发提供支持.然而数据质量对相关的研究和实践有重大影响,却还没有得到足够的重视.为了能够更好地警示数据使用者潜在的数据质量问题,通过文献调研和访谈,并基于自有经验对数据进行分析,总结出了9种数据质量问题,覆盖了数据产生、数据收集和数据使用这3个不同的阶段.进一步地,提出了相应的方法以帮助发现和解决数据问题.发现问题是指加强对数据上下文的理解和通过统计分析及数据可视化发现潜在的数据质量问题,解决问题是指利用冗余数据或者挖掘用户行为模式进行修正.     

一种面向软件配置管理制品的层次分类方法

配置管理工具（Configuration Management Tool,CMT）作为运维自动化的组成部分,是实现开发运维一体化（Development and Operations,DevOps）的重要支撑技术.当前互联网开源社区中存在数量众多CMT脚本制品,但是缺乏有效的层次分类管理,给快速检索和高效利用CMT脚本制品造成困难.针对该问题,提出一种面向CMT制品的基于在线非结构化描述文档分析的层次分类方法.该方法利用标签共现性关系（tag co-occurrence）建立层次类别体系,基于描述属性特征,实现对CMT制品的层次分类器;并使用混合的样本划分方式针对“数据倾斜”问题进行了改进.对超过11000例训练数据和1000例测试数据进行实验,结果表明,改进的样本划分方式得到的最佳查准率、查全率、调和平均值分别达到0.81、0.88、0.85,较传统方式查全率提高0.15,调和平均值提高0.06,该结果验证了层次分类方法的有效性.     

面向微服务架构的开发组织适应性评估框架

目前,一种称为微服务的架构风格正受到越来越多的关注.其给软件项目带来好处的同时,也影响着使用微服务架构的开发组织.本文的研究目的是明确微服务的使用对开发组织产生了哪些影响,这些影响对于组织来说是优势还是挑战.对此本文进行了一次系统文献综述,并通过元-民族志对定性数据进行合成,最终得出了使用微服务架构对组织产生影响的7个方面,分别是：组织结构、自治团队、技术/工具、组织文化、开发人员、DevOps以及通信.同时基于系统文献综述的结果本文发现,虽然大量微服务的研究都强调为了充分获取微服务带来的预期收益,就必须解决组织问题,但是目前针对组织问题发表的学术文献依然较少,因此本文将那些可能更接近于工业界观点的、高质量的灰色文献也纳入到工作中.根据系统文献综述的结果以及对定性数据的合成,得出了四条更高阶的解释并提出了一个适应性评估框架,此评估框架可以帮助公司评估并提高开发组织对于微服务架构的适应性,为开发组织在面向微服务开发的过程中提供了指导意见.最后,为了验证所提出的适应性评估框架,本文面向工业界设计并实施了有针对性的问卷调查和行业访谈,两者的结果验证了所提出的适应性评估框架的有效性.     

DevSecOps:DevOps下实现持续安全的实践探索

国内外各大软件企业正广泛实施DevOps相关实践,以提高产品交付和部署频率.与此同时,面对日益严峻的网络安全环境,软件系统中的安全问题日益凸显.耗时的安全实践因为快速交付,在软件开发活动中难以得到有效贯彻.也正因如此,在开发和运维流程中有效集成安全控制手段,实现整个软件生命周期的持续安全,已成为各大企业向DevOps转型过程中亟需思考的问题.DevSecOps作为在DevOps下持续解决安全问题的有效方案,因此而受到学术界和工业界的广泛关注,并逐渐成为软件工程领域的研究重点.近年来,随着DevSecOps的研究和实践发展,人们对DevSecOps有了更全面的认识,也引入了更多安全实践.为此,从DevSecOps的背景、特征、实践、裨益和挑战这5个方面进行了归纳和总结,首次向国内软件工程社区全面介绍DevSecOps的核心内容,重点阐述了DevSecOps最新的理论研究和工业界实践现状,进而为从业者实际落地DevSecOps提供参考,也为研究者探索DevSecOps提供便利,并呼吁更多的研究者参与到DevSecOps的研究中来.     

新型信息化系统建设下的敏捷开发模式

当今社会,敏捷逐渐成为业界的主流开发模式,越来越多的组织成功实现了敏捷转型,在研发效率提升和客户价值等方面成绩斐然.敏捷已经从传统纯研发领域,向前延伸到了业务敏捷,向后扩展实现了DevOps开发运维一体化.为快速响应和满足用户需求,缩短系统建设周期,避免因业务变化导致的开发工作浪费,保证产品交付质量,公司决定研发敏捷转型,选取经法2.0系统、人资2.0系统作为敏捷迭代开发试点项目.以用户为中心主动创新、敢于试错,着力推进系统的敏捷迭代、小步快跑,创新优化系统建设模式.目标是通过敏捷转型实现快速高质量的完成项目交付,并总结转型经验同时梳理出适用于国网敏捷项目的制度、标准、流程以及相关的支撑工具.本文从工作思路、实践过程和做法、建设成效3方面介绍敏捷开发模式下如何提升软件质量.     

DevDocOps: Enabling continuous documentation in alignment with DevOps

The proliferation of DevOps enables significant acceleration and automation of the delivery and deployment of massive software products. Unfortunately, the development of supporting documents that is vital for large-scale software systems in many cases does not keep pace with the rhythm of feature delivery using DevOps in practice, which becomes the bottleneck for many software organizations to deliver full value to the customers as claimed by the DevOps. This paper proposes, implements, and evaluates an integrated approach, DevDocOps, for continuous automated documentation, in particular for DevOps. With DevDocOps, supporting documents are created along with the development process simultaneously by various roles within a DevOps project, which largely guarantees the accuracy and integrity of documents as well as significantly increases their delivery speed. Within an established delivery chain, a set of templates are created to collect and transform the required information from its origin to the target documents for delivery. A real system, iDoc, is implemented to map, collect, and synthesize the information from document templates and automate the documentation process. DevDocOps has been successfully adopted in a top-tier global telecommunication enterprise to support more than 5000 users with different roles related to documentation. The lag time between the releases of the product version and its supporting document has been shortened from 1 to 2 months on average to less than 2 days. DevDocOps extends the scope of DevOps and enhances the value delivery by supporting continuous documentation and bridges the gap between feature delivery and document delivery with automation.     

Problems and their mitigation in system and software architecting

ContextToday, software and embedded systems act as enablers for developing new functionality in traditional industries such as the automotive, process automation, and manufacturing automation domains. This differs from 25–30 years ago when these systems where based on electronics and electro-mechanical solutions. The architecture of the embedded system and of the software is important to ensure the qualities of these applications. However, the effort of designing and evolving the architecture is in practice often neglected during system development, whilst development efforts are centered on implementing new functionality.ObjectiveWe present problems and success factors that are central to the architectural development of software intensive systems in the domain of automotive and automation products as judged by practitioners.MethodThe method consisted of three steps. First, we used semi-structured interviews to collect data in an exploratory manner. As a second step, a survey based on problems extracted from the interview data was used to investigate the occurrence of these problems at a wider range of organizations. In order to identify and suggest how to mitigate the problems that were considered important, we finally performed root cause analysis workshops, and from these a number of success factors were elicited.ResultsA total of 21 problems have been identified based on the interview data, and these are related to the technical, organizational, project, and agreement processes. Based on the survey results, the following four problems were selected for a root cause analysis: (1) there is a lack of process for architecture development, (2) there is a lack of method or model to evaluate the business value when choosing the architecture, (3) there is a lack of clear long-term architectural strategy, and (4) processes and methods are less valued than knowledge and competence of individuals.ConclusionIn conclusion, the following identified success factors are crucial components to be successful in developing software intensive systems: (1) define an architectural strategy, (2) implement a process for architectural work, (3) ensure authority for architects, (4) clarify the business impact of the architecture, and (5) optimize on the project portfolio level instead of optimizing each project.     

Is it worth adopting DevOps practices in Global Software Engineering? Possible challenges and benefits

The software industry is adopting the DevOps paradigm to an increasingly frequent extent. In addition, the trend of developing software in a distributed manner greatly increased as a result of the COVID-19 pandemic, which forced team members from software companies to work remotely. We present the results of a Systematic Mapping Study (SMS) of how DevOps has been applied in distributed and global settings that adopts Global Software Development (GSD). The results were obtained from analysing 27 papers. The main conclusions obtained after carrying our SMS show that adopting DevOps in such settings by implementing certain practices brings several advantages to software companies, even though there are difficulties to be confronted when adopting DevOps in global and distributed contexts. Moreover, we (1) proposed definition of DevOps in distributed and global settings, (2) mapped the challenges detected with a list of well-known GSD risks and (3) mapped the benefits that can be obtained from applying certain practices identified and the challenges that should be overcame to obtain such benefits.     

A systematic literature review on the usage of eye-tracking in software engineering

ContextEye-tracking is a mean to collect evidence regarding some participants’ cognitive processes. Eye-trackers monitor participants’ visual attention by collecting eye-movement data. These data are useful to get insights into participants’ cognitive processes during reasoning tasks.ObjectiveThe Evidence-based Software Engineering (EBSE) paradigm has been proposed in 2004 and, since then, has been used to provide detailed insights regarding different topics in software engineering research and practice. Systematic Literature Reviews (SLR) are also useful in the context of EBSE by bringing together all existing evidence of research and results about a particular topic. This SLR evaluates the current state of the art of using eye-trackers in software engineering and provides evidence on the uses and contributions of eye-trackers to empirical studies in software engineering.MethodWe perform a SLR covering eye-tracking studies in software engineering published from 1990 up to the end of 2014. To search all recognised resources, instead of applying manual search, we perform an extensive automated search using Engineering Village. We identify 36 relevant publications, including nine journal papers, two workshop papers, and 25 conference papers.ResultsThe software engineering community started using eye-trackers in the 1990s and they have become increasingly recognised as useful tools to conduct empirical studies from 2006. We observe that researchers use eye-trackers to study model comprehension, code comprehension, debugging, collaborative interaction, and traceability. Moreover, we find that studies use different metrics based on eye-movement data to obtain quantitative measures. We also report the limitations of current eye-tracking technology, which threaten the validity of previous studies, along with suggestions to mitigate these limitations.ConclusionHowever, not withstanding these limitations and threats, we conclude that the advent of new eye-trackers makes the use of these tools easier and less obtrusive and that the software engineering community could benefit more from this technology.