一种企业代码成果管控系统的设计研究

来源:用户上传      作者:夏维嘉 江涛 董志刚 李海 薛亮 张媛

　　[摘    要] 对于软件项目来讲，整个项目的投入最终的知识成果累积核心就在最后交付的成果代码和文档，此成果承载着企业的生产管理业务逻辑以及算法经验，是软件项目最重要的资产。对于最重要的成果之一，但企业往往只重视代码编译生成的软件应用，缺少对代码的质量评测，同时代码成果入库及出库的随机性导致软件知识成果大量流失，没有代码、低品质代码，代码作为个人或开发单位的私产被保存的情况大量存在。导致软件持续开发、集成困难，重复开发、代码丢失、代码缺陷等问题突出。按照DevOps模式构建一种企业代码成果管控体系，并以此为蓝图设计一套代码成果管控系统，实现代码成果的规范管理，进一步支持企业系统持续开发，持续集成。
　　[关键词] 代码管控;DevOps;GitLab;持续开发;持续集成
　　doi ： 10 . 3969 / j . issn . 1673 - 0194 . 2020. 05. 039
　　[中图分类号] F270.7    [文献标识码]  A      [文章编号]  1673 - 0194（2020）05- 0085- 04
　　0      引    言
　　软件成果属于知识型成果，此成果承载着企业的生产管理业务逻辑以及算法经验，是软件项目最重要的资产。但企业往往只重视代码编译生成的软件应用，忽视对代码的管控。目前常见的管控手段是由开发方提交成果，人工归档，没有统一的标准对代码成果的真实性、有效性、品质做相应的评审。代码成果入库及出库的随机性导致软件知识成果大量流失。没有代码、低品质代码，代码作为个人或开发单位的私产被保存的情况大量存在。导致以下几种现象：
　　第一：增大软件持续开发难度。软件的存在是为了满足企业生产经营管理需要，随着生产技术和管理方法的改进，软件也要持续同步改造。我们不难想象没有代码、代码质量很低将对我们的业务带来什么影响？越往后需求响应周期越长，甚至无法响应。案例1：某公司2015年的系统2016更换开发公司后全部重新开发。案例2：仅2014年以来，有5-6个系统因为硬件环境改变导致系统无法部署继续运行（只有1个自开发系统修改代码后可正常运行）。
　　第二：原系统追溯成本高，甚至高于重新开发成本。因为原代码的缺失，若在生产过程中发生了数据泄密或历史数据丢失，要想追溯往往需要10倍以上的成本。案例1：某油田系统开发费3万元，取历史数据400万元。
　　第三：知识产权流失，数据失泄密风险高。2014年信息安全评估结果，5个系统因代码缺陷无法通过，被迫停止运行，重新改进。
　　导致上述问题的出现是多方面的，其中代码管控（Code Review）过程中[1]，缺少代码成果质量严格评测并提交代码进行保存转化是主要原因之一。代码质量代表着系统的有序程度，烂代码增加就是系统无序性上升的体现。每个不同的程序员编写的代码，甚至同一个程序员不同时期编写的代码，代码质量是无序的、随机的。在项目开发过程中，在没有外力影响的情况下，烂代码只会越来越多。为了维持系统有序，需要多管齐下，主动对代码质量进行管控，并且持续进行技术升级，系统性地解决问题。需要有意识地投入资源来建设代码质量的管控体系，这个体系的名称是DevOps[2]。
　　1      DevOps
　　DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。DevOps可以提供高效稳定的、可持续的、可协调的、自动化的代码管控手段。DevOps希望做到的是软件产品交付过程中IT工具链的打通，使得各个团队减少时间损耗，更加高效地协同工作。专家们总结出了DevOps能力环，良好的闭环可以大大增加整体的产出。
　　1.1   DevOps原理
　　DevOps将开发延伸至生产中——包括拓展持续集成和发布功能至生产，集成QA和信息安全至整个工作流，确保代码和环境可在生产中直接部署。DevOps向开发中加入生产反馈——包括建立开发和IT运营事件的完整时间表用于帮助事件的解决，使得开发融入无指责的生产反思，尽可能使得开发可以自助服务，同时创建信息指示器用来表明本地的决策如何影响全局的目标。DevOps将开发嵌入到IT运维中——包括开发投入到整个生产问题处理链，分配开发资源用于生产问题管理，并协助退回技术债务，开发为IT运维提供交叉培训，增加IT运维处理问题的能力，从而降低升级问题的数量。DevOps将IT运维嵌入至开发——包括嵌入和联络IT运维资源至开发，帮助开发创建为IT运维（部署，生产代码的管理等）使用的可重用的用户故事，定义一些可以被所有项目共用的非功能性需求。
　　1.2   DevOps带来的好处
　　（1）更小、更频繁的变更──意味着更少的风险。
　　（2）讓开发人员更多地控制生产环境。
　　（3）更多地以应用程序为中心来理解基础设施。
　　（4）定义简洁明了的流程。
　　（5）尽可能地自动化。
　　（6）促成开发与运营的协作。
　　2      代码成果管控体系设计
　　按照DevOps体系原理设计一种代码成果管控体系，实现代码成果的规范管理、质量评测与安全可控，进一步支持企业系统持续开发，持续集成[3]。
　　2.1   解决的问题
　　（1）代码成果规范。面对不同的软件开发团队，多样化的技术实现方式和语言，如何形成一套普适的代码规范、安装测试文档规范？这里不只涉及代码基本的格式还包括一些重要的功能和检测方面，如必须在运行环节加上异常消息机制代码等。 　　（2）代码成果入库质量评审、检测。重点需要制定代码资产的入库评审检测体系，固化流程和方法。例如如何评审、谁来评审、评审哪些内容、评审到什么粒度，针对不同形式的成果如何测试、测试哪些内容等。
　　（3）代码成果存储、运维。建立怎样的存储及运维体系，从而保证成果存放的有序及高效检索、安全保密是关键。
　　（4）代码成果出库安全受控分享应用以及如何保证分享安全受控等。
　　2.2   实现的功能
　　代码管控应实现表1中的功能。
　　2.3   流程设计
　　通过代码管控一个项目可能由多家软件公司开发完成。企业掌握项目的所有源代码，而各家软件公司只掌握自己公司的源代码，软件公司之间不能互相访问源代码，软件公司更不允许访问项目的全部代码。实现这个要求，需要把项目进行派生[4]。派生是创建项目仓库的副本，只有派生的项目之间才可以进行合并。项目的创建和派生都由企业的项目终审员一个人完成。所有项目在物理上都是不同的项目，但项目名称是相同的，这就要求必须新建不同的“群组”来存储这些项目，然后通过不同的路径来访问这些项目。 群组的工作方式就像一个文件夹，可以向群组中添加“成员”用户，并给每个群组成员指定角色。群组中的成员权限可以横向和向下传播：即群组中的成员角色权限可以传递给本群组和所有子群组中的所有项目。
　　2.4   技术选型
　　现阶段有两个主要的商用DevOps平台，分别是微软Azure DevOps和IBM DevOps Services。
　　2.4.1   Microsoft Azure DevOps
　　微软于2018年宣布推出Azure DevOps，它是Visual Studio Team Services的继任者，以帮助开发人员更快地交付软件并提供更高质量的软件。DevOps 汇集人员、流程和技术，实现软件交付自动化，为用户提供持续的价值。借助 Azure DevOps 解决方案，无论 IT 部门有多大规模或使用何种工具，都可以更加快速可靠地交付软件。
　　2.4.2   IBM Jazz
　　Jazz 是 IBM Rational 面向软件交付技术的下一代协作平台，是一个可扩充、可扩展的团队协作平台，可以无缝整合软件与系统开发生命周期中的工作。Jazz旨在推动广大软件开发人员考虑摒弃单人开发工具，转而采用多人协作开发工具，以实现各人员间步调更一致的沟通与协作。Jazz 使用一种名为“开放商业软件开发”的新形式进行开发。Jazz 的开发工作在 Jazz.net 以开放的方式进行。这种开放性和透明性的好处在于，它允许客户成为持续反馈循环的一部分，以便推动开发决策。您可以通过 Jazz.net 了解开发工作的进展情况。
　　2.4.3   GitLab
　　虽然Microsoft Azure DevOps和IBM Jazz都是重要的DevOps平台，功能也很强大，但两套系统并不兼容，不能选择这两个平台作为开发和代码管控平台。主要的原因如下：
　　（1）系统过于复杂，模块过多，软件开发者和使用者都不容易掌握，如果要使用这些系统，会付出高昂的培训费用。
　　（2）不能在本公司内部搭建Azure DevOps和IDB Jazz平台，有代码泄露的风险。
　　（3）使用成本高。两个系统都需要支付用户费用。以Azure DevOps为例，Azure DevOps对于开源项目和小项目（最多五个用户）是免费的。但是对于大型团队，费用从每月30美元（10个用户）到每月6 150美元（1 000个用户）。
　　综上所述，必须要选择可靠、易用、费用低廉并且能自我维护的代码管控平台[3]。根据前期评估。选择GitLab作为代码管控平台[2]。最主要的理由就是GitLab支持企業内部自主搭建，功能全面，成熟。
　　GitLab是一款免费的、开源的、分布式的版本控制系统。旨在快速高效地处理无论规模大小的任何软件工程。每一个 Git克隆都是一个完整的文件库，含有全部历史记录和修订追踪能力，不依赖于网络连接或中心服务器。其最大特色就是“分支”及“合并”操作非常快速、简便。GitLab 是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的Web服务。Gitlab是一个用Ruby on Rails开发的开源项目管理程序，可以通过WEB界面进行访问公开的或者私人项目。它能够浏览源代码，管理缺陷和注释。GitLab具有完整的分支管理和用户管理功能，能够完成各种项目的源代码及版本的管控。其核心功能包括：
　　（1）软件项目（资料库）管理;
　　（2）标签管理;
　　（3）分配成员角色;
　　（4）锁定受保护的分支;
　　（5）发起、审查、处理合并请求;
　　（6）代码评论;
　　（7）代码片段管理;
　　（8）邮件通知;
　　（9）持续集成。
　　除此之外，GitLab还是一个开源系统，开发接口，允许第三方软件接入。目采用GitLab可以很方便地将本公司内部的管理人员与第三方软件公司的程序人员整合在一个平台上，各自扮演自己的角色，最后完成代码成果规范、代码成果入库质量评审、检测、代码成果存储、运维以及代码成果出库等既定目标的工作。
　　3      代码成果管控系统设计实现
　　基于GitLab代码库构建代码成果管控系统，整个系统由代码项目服务、代码库服务、代码评审服务3个关键服务构成。 　　3.1   系统整体架构
　　系统整体架构如图2所示。
　　3.2   基础服务体系
　　3.2.1   用户
　　用戶管理模块提供对用户信息的管理，包括用户注册、用户登录、用户权限管理、用户信息修改以及用户等级修改。
　　3.2.2   日志
　　一个合格的系统不仅仅要求具有运行的高效和计算的准确，同时又必须兼顾稳定性、可靠性。其次，对于开发人员来说，又必须具有可拓展性和可维护性。为了快速、准确地对bug进行定位分析和解决，在系统设计、开发和实现的过程中必须注意日志的记录，这将会对于日后的系统监控和异常分析起至关重要的作用。
　　3.2.3   权限
　　权限管理进行权限检测，让经过授权的用户可以正常合法的使用已授权的功能，而对那些未授权的非法用户拒之门外。权限管理对于代码成果管控系统至关重要。由于代码是企业的核心资产和商业机密，不能透露给非授权用户，因此要对用户进行授权、鉴权，保证未授权用户不能接触到相关内容。
　　3.2.4   动态表单
　　动态表单是用拖拽的方式创建表单，到指派对应的工作流，再到表单的使用和归档的一整套功能。创建好的表单可以分类保存，使用者可以重用它们。
　　动态表单的目的是为了根据业务流程不同灵活设计显示页面，在业务流程设计阶段不用过多地考虑表单如何实现，将业务流程与表单显示分离开了，充分体现了系统的灵活性。
　　3.2.5   流程引擎
　　流程引擎作为应用系统的一部分，并为之提供对各应用系统有决定作用的根据角色、分工和条件的不同决定信息传递路由、内容等级等核心解决方案。流程引擎包括流程的节点管理、流向管理、流程样例管理等重要功能。
　　3.2.6   消息通知
　　为了让用户获得需要得到的消息及提醒并进行处理，如处理工作流中的审批、用户彼此互动触发的信息流（留言、评论或者回复、私信等）、系统希望用户了解关注的信息（系统公告等）等相关信息，通过特定的通知渠道（邮件、短信、站内消息等），将消息内容发送到特定的用户。
　　3.2.7   附件
　　在代码管控的过程中，作为系统的必要补充，用户将会上传例如：需求规程说明书、详细设计说明书、用户手册等相关内容，这些内容作为附件与系统代码一起统一管理。因此，附件模块提供文件上传、下载、删除等相关功能。
　　3.2.8   GitLab
　　GitLab是代码成果管控系统最基础、最核心的功能，所有的代码都存储在GitLab中。GitLab具有完整的分支管理和用户管理功能，能够完成各种项目的源代码及版本的管控。
　　3.2.9   LADP
　　轻型目录访问协议（LDAP）是一个开放的，中立的，工业标准的应用协议，通过IP协议提供访问控制和维护分布式信息的目录信息。目录服务在开发内部网和与互联网程序共享用户、系统、网络、服务和应用的过程中占据了重要地位。
　　3.3   代码库服务
　　代码库服务提供以Git为基础的日常开发源代码版本管理，包括代码浏览、分？管理、发布管理、版本对比、合并请求、项？？络等，提供强于Git 的代码管理使用体验。
　　在对代码进行管理时，需要对代码分支管理做一定规范，将GitLab划分四种分支，dev，test，master，hotfix。将四种分支分属开发，测试，主干、修复四个角色进行管理。
　　3.3.1   开发（dev）
　　开发人员将功能分支代码合并到dev分支后，触发构建过程，代码打包，镜像构建等，完成构建后，通过容器管理平台将新构建的镜像进行发布。
　　3.3.2   测试（test）
　　当开发人员将代码交付测试部门时，测试人员，将代码merge到test分支中，此时触发测试分支的构建的流程，完成构建后，通过管理平台进行测试环境的发布。
　　3.3.3   主干（master）
　　测试验收通过后，交付运维团队进行上线升级，将代码合并到master分支中，构建release版本信息，构建完成后，发布应用。
　　3.3.4   问题修改（hotfix）
　　用于修复线上问题，从对应线上版本的拉取，修改并测试完成后合并到master，在master测试完成后，从master发布
　　3.4   项目服务
　　3.4.1   创建项目
　　每个项目都有属于它自己的相应代码，所以在管理代码之前，应该先建立相应的项目信息。建立好项目之后，才能将代码仓库与项目进行关联。
　　3.4.2   项目管理
　　项目管理模块对项目的详细信息进行编辑修改，维护项目资料，以及由管理员决定启用或禁用该项目，以管理项目从建立到结束作为整个生命周期。
　　3.4.3   版本管理
　　所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库进行版本管理，确保版本的准确性和可追溯性。
　　3.4.4   代码库
　　代码库应归属于某个项目，不应该单独存在，并且1个项目可能包括0或多个代码库。用户通过代码库模块，直接管理和维护位于GitLab上的代码仓库。 　　3.5   评审服务
　　软件测试本身有一定的局限性，在检测软件缺陷中，单元测试发现缺陷的比例大概是25%，功能测试占到35%，集成测试占到45%。相比之下，设计和代码审查的效率要高很多，发现缺陷的比例可以达到55%-60%。对审查结果的案例学习对项目的帮助也非常大。
　　3.5.1   缺陷分类
　　预先建立缺陷分类，如：需求错误、命名不规范、性能不足等，方便在代码评审完成之后进行相关检索，快速定位缺陷。
　　3.5.2   缺陷记录
　　对在代码评审过程中发现的问题，记录到系统之中，形成记录，并指派给相应责任人，避免评审的形式主义，确保每个缺陷都有人负责。
　　3.5.3   统计分析
　　对评审出来的缺陷进行统计分析，形成报表，以此对开发人员或供应商进行评估，分析他们的能力，为后续的工作提供数据支撑。
　　3.6   用户服务
　　3.6.1   开发者
　　开发者是要审查的代码的作者，负责代码的编写、调试，以及Bug的修改。
　　3.6.2   供應商
　　供应商是代码的所有者，并且也是发起审查活动的人。
　　3.6.3   审查者
　　审查者是审查代码并且要报告审查结果给开发者和供应商的人。
　　4      方案测试
　　为了验证本文提出的代码成果管控功能的可行性和可靠性，开发了一套代码陈成果管控系统，参照K8S+docker架构搭建了系统，对某企业四个应用系统进行代码入库与代码编译验证、系统部署测试、系统安全测评工作。代码编译验证和系统部署测试平均所用时间由2天左右缩短为1天左右，系统安全测评时间由10天缩短为6天左右。经测算，同等测试工作量下，测评效率提高40%左右。同时代码相关资料完整性从原来的75%上升到95%。
　　5      结    语
　　通过测试证明，代码成果管控系统可有效管控企业软件开发形成的各类代码成果，并可进行代码安全分发，支持系统的持续开发与持续集成。使得软件系统的构建、测试、发布更加快捷、频繁和可靠。
　　主要参考文献
　　[1]汪佩华.软件开发团队中代码管理和版本控制[J].计算机与软件，2017（20）：78.
　　[2]Sanjeev Sharma，Bernie Coyne.DevOps for Dummies IBM[M].2nd edition.NewYork，NY：John Wiley & Sons，Inc，2017.
　　[3]董昕，郭勇，王杰.基于DevOps能力模型的持续集成方法[J].计算机工程与设计，2018，39（7）：1930-1937.
转载注明来源:https://www.xzbu.com/3/view-15142182.htm