一種企業(yè)代碼成果管控系統(tǒng)的設(shè)計(jì)研究

夏維嘉 江濤 董志剛 李海 薛亮 張媛

[摘? ? 要] 對于軟件項(xiàng)目來講，整個(gè)項(xiàng)目的投入最終的知識成果累積核心就在最后交付的成果代碼和文檔，此成果承載著企業(yè)的生產(chǎn)管理業(yè)務(wù)邏輯以及算法經(jīng)驗(yàn)，是軟件項(xiàng)目最重要的資產(chǎn)。對于最重要的成果之一，但企業(yè)往往只重視代碼編譯生成的軟件應(yīng)用，缺少對代碼的質(zhì)量評測，同時(shí)代碼成果入庫及出庫的隨機(jī)性導(dǎo)致軟件知識成果大量流失，沒有代碼、低品質(zhì)代碼，代碼作為個(gè)人或開發(fā)單位的私產(chǎn)被保存的情況大量存在。導(dǎo)致軟件持續(xù)開發(fā)、集成困難，重復(fù)開發(fā)、代碼丟失、代碼缺陷等問題突出。按照DevOps模式構(gòu)建一種企業(yè)代碼成果管控體系，并以此為藍(lán)圖設(shè)計(jì)一套代碼成果管控系統(tǒng)，實(shí)現(xiàn)代碼成果的規(guī)范管理，進(jìn)一步支持企業(yè)系統(tǒng)持續(xù)開發(fā)，持續(xù)集成。

[關(guān)鍵詞] 代碼管控;DevOps;GitLab;持續(xù)開發(fā);持續(xù)集成

doi ： 10 . 3969 / j . issn . 1673 - 0194 . 2020. 05. 039

[中圖分類號] F270.7? ? [文獻(xiàn)標(biāo)識碼]? A? ? ? [文章編號]? 1673 - 0194（2020）05- 0085- 04

0? ? ? 引? ? 言

軟件成果屬于知識型成果，此成果承載著企業(yè)的生產(chǎn)管理業(yè)務(wù)邏輯以及算法經(jīng)驗(yàn)，是軟件項(xiàng)目最重要的資產(chǎn)。但企業(yè)往往只重視代碼編譯生成的軟件應(yīng)用，忽視對代碼的管控。目前常見的管控手段是由開發(fā)方提交成果，人工歸檔，沒有統(tǒng)一的標(biāo)準(zhǔn)對代碼成果的真實(shí)性、有效性、品質(zhì)做相應(yīng)的評審。代碼成果入庫及出庫的隨機(jī)性導(dǎo)致軟件知識成果大量流失。沒有代碼、低品質(zhì)代碼，代碼作為個(gè)人或開發(fā)單位的私產(chǎn)被保存的情況大量存在。導(dǎo)致以下幾種現(xiàn)象：

第一：增大軟件持續(xù)開發(fā)難度。軟件的存在是為了滿足企業(yè)生產(chǎn)經(jīng)營管理需要，隨著生產(chǎn)技術(shù)和管理方法的改進(jìn)，軟件也要持續(xù)同步改造。我們不難想象沒有代碼、代碼質(zhì)量很低將對我們的業(yè)務(wù)帶來什么影響？越往后需求響應(yīng)周期越長，甚至無法響應(yīng)。案例1：某公司2015年的系統(tǒng)2016更換開發(fā)公司后全部重新開發(fā)。案例2：僅2014年以來，有5-6個(gè)系統(tǒng)因?yàn)橛布h(huán)境改變導(dǎo)致系統(tǒng)無法部署繼續(xù)運(yùn)行（只有1個(gè)自開發(fā)系統(tǒng)修改代碼后可正常運(yùn)行）。

第二：原系統(tǒng)追溯成本高，甚至高于重新開發(fā)成本。因?yàn)樵a的缺失，若在生產(chǎn)過程中發(fā)生了數(shù)據(jù)泄密或歷史數(shù)據(jù)丟失，要想追溯往往需要10倍以上的成本。案例1：某油田系統(tǒng)開發(fā)費(fèi)3萬元，取歷史數(shù)據(jù)400萬元。

第三：知識產(chǎn)權(quán)流失，數(shù)據(jù)失泄密風(fēng)險(xiǎn)高。2014年信息安全評估結(jié)果，5個(gè)系統(tǒng)因代碼缺陷無法通過，被迫停止運(yùn)行，重新改進(jìn)。

導(dǎo)致上述問題的出現(xiàn)是多方面的，其中代碼管控（Code Review）過程中[1]，缺少代碼成果質(zhì)量嚴(yán)格評測并提交代碼進(jìn)行保存轉(zhuǎn)化是主要原因之一。代碼質(zhì)量代表著系統(tǒng)的有序程度，爛代碼增加就是系統(tǒng)無序性上升的體現(xiàn)。每個(gè)不同的程序員編寫的代碼，甚至同一個(gè)程序員不同時(shí)期編寫的代碼，代碼質(zhì)量是無序的、隨機(jī)的。在項(xiàng)目開發(fā)過程中，在沒有外力影響的情況下，爛代碼只會越來越多。為了維持系統(tǒng)有序，需要多管齊下，主動(dòng)對代碼質(zhì)量進(jìn)行管控，并且持續(xù)進(jìn)行技術(shù)升級，系統(tǒng)性地解決問題。需要有意識地投入資源來建設(shè)代碼質(zhì)量的管控體系，這個(gè)體系的名稱是DevOps[2]。

1? ? ? DevOps

DevOps（Development和Operations的組合詞）是一組過程、方法與系統(tǒng)的統(tǒng)稱，用于促進(jìn)開發(fā)（應(yīng)用程序/軟件工程）、技術(shù)運(yùn)營和質(zhì)量保障（QA）部門之間的溝通、協(xié)作與整合。DevOps可以提供高效穩(wěn)定的、可持續(xù)的、可協(xié)調(diào)的、自動(dòng)化的代碼管控手段。DevOps希望做到的是軟件產(chǎn)品交付過程中IT工具鏈的打通，使得各個(gè)團(tuán)隊(duì)減少時(shí)間損耗，更加高效地協(xié)同工作。專家們總結(jié)出了DevOps能力環(huán)，良好的閉環(huán)可以大大增加整體的產(chǎn)出。

1.1? ?DevOps原理

DevOps將開發(fā)延伸至生產(chǎn)中——包括拓展持續(xù)集成和發(fā)布功能至生產(chǎn)，集成QA和信息安全至整個(gè)工作流，確保代碼和環(huán)境可在生產(chǎn)中直接部署。DevOps向開發(fā)中加入生產(chǎn)反饋——包括建立開發(fā)和IT運(yùn)營事件的完整時(shí)間表用于幫助事件的解決，使得開發(fā)融入無指責(zé)的生產(chǎn)反思，盡可能使得開發(fā)可以自助服務(wù)，同時(shí)創(chuàng)建信息指示器用來表明本地的決策如何影響全局的目標(biāo)。DevOps將開發(fā)嵌入到IT運(yùn)維中——包括開發(fā)投入到整個(gè)生產(chǎn)問題處理鏈，分配開發(fā)資源用于生產(chǎn)問題管理，并協(xié)助退回技術(shù)債務(wù)，開發(fā)為IT運(yùn)維提供交叉培訓(xùn)，增加IT運(yùn)維處理問題的能力，從而降低升級問題的數(shù)量。DevOps將IT運(yùn)維嵌入至開發(fā)——包括嵌入和聯(lián)絡(luò)IT運(yùn)維資源至開發(fā)，幫助開發(fā)創(chuàng)建為IT運(yùn)維（部署，生產(chǎn)代碼的管理等）使用的可重用的用戶故事，定義一些可以被所有項(xiàng)目共用的非功能性需求。

1.2? ?DevOps帶來的好處

（1）更小、更頻繁的變更──意味著更少的風(fēng)險(xiǎn)。

（2）讓開發(fā)人員更多地控制生產(chǎn)環(huán)境。

（3）更多地以應(yīng)用程序?yàn)橹行膩砝斫饣A(chǔ)設(shè)施。

（4）定義簡潔明了的流程。

（5）盡可能地自動(dòng)化。

（6）促成開發(fā)與運(yùn)營的協(xié)作。

2? ? ? 代碼成果管控體系設(shè)計(jì)

按照DevOps體系原理設(shè)計(jì)一種代碼成果管控體系，實(shí)現(xiàn)代碼成果的規(guī)范管理、質(zhì)量評測與安全可控，進(jìn)一步支持企業(yè)系統(tǒng)持續(xù)開發(fā)，持續(xù)集成[3]。

2.1? ?解決的問題

（1）代碼成果規(guī)范。面對不同的軟件開發(fā)團(tuán)隊(duì)，多樣化的技術(shù)實(shí)現(xiàn)方式和語言，如何形成一套普適的代碼規(guī)范、安裝測試文檔規(guī)范？這里不只涉及代碼基本的格式還包括一些重要的功能和檢測方面，如必須在運(yùn)行環(huán)節(jié)加上異常消息機(jī)制代碼等。

（2）代碼成果入庫質(zhì)量評審、檢測。重點(diǎn)需要制定代碼資產(chǎn)的入庫評審檢測體系，固化流程和方法。例如如何評審、誰來評審、評審哪些內(nèi)容、評審到什么粒度，針對不同形式的成果如何測試、測試哪些內(nèi)容等。

（3）代碼成果存儲、運(yùn)維。建立怎樣的存儲及運(yùn)維體系，從而保證成果存放的有序及高效檢索、安全保密是關(guān)鍵。

（4）代碼成果出庫安全受控分享應(yīng)用以及如何保證分享安全受控等。

2.2? ?實(shí)現(xiàn)的功能

代碼管控應(yīng)實(shí)現(xiàn)表1中的功能。

2.3? ?流程設(shè)計(jì)

通過代碼管控一個(gè)項(xiàng)目可能由多家軟件公司開發(fā)完成。企業(yè)掌握項(xiàng)目的所有源代碼，而各家軟件公司只掌握自己公司的源代碼，軟件公司之間不能互相訪問源代碼，軟件公司更不允許訪問項(xiàng)目的全部代碼。實(shí)現(xiàn)這個(gè)要求，需要把項(xiàng)目進(jìn)行派生[4]。派生是創(chuàng)建項(xiàng)目倉庫的副本，只有派生的項(xiàng)目之間才可以進(jìn)行合并。項(xiàng)目的創(chuàng)建和派生都由企業(yè)的項(xiàng)目終審員一個(gè)人完成。所有項(xiàng)目在物理上都是不同的項(xiàng)目，但項(xiàng)目名稱是相同的，這就要求必須新建不同的“群組”來存儲這些項(xiàng)目，然后通過不同的路徑來訪問這些項(xiàng)目。 群組的工作方式就像一個(gè)文件夾，可以向群組中添加“成員”用戶，并給每個(gè)群組成員指定角色。群組中的成員權(quán)限可以橫向和向下傳播：即群組中的成員角色權(quán)限可以傳遞給本群組和所有子群組中的所有項(xiàng)目。

2.4? ?技術(shù)選型

現(xiàn)階段有兩個(gè)主要的商用DevOps平臺，分別是微軟Azure DevOps和IBM DevOps Services。

2.4.1? ?Microsoft Azure DevOps

微軟于2018年宣布推出Azure DevOps，它是Visual Studio Team Services的繼任者，以幫助開發(fā)人員更快地交付軟件并提供更高質(zhì)量的軟件。DevOps 匯集人員、流程和技術(shù)，實(shí)現(xiàn)軟件交付自動(dòng)化，為用戶提供持續(xù)的價(jià)值。借助 Azure DevOps 解決方案，無論 IT 部門有多大規(guī)?；蚴褂煤畏N工具，都可以更加快速可靠地交付軟件。

2.4.2? ?IBM Jazz

Jazz 是 IBM Rational 面向軟件交付技術(shù)的下一代協(xié)作平臺，是一個(gè)可擴(kuò)充、可擴(kuò)展的團(tuán)隊(duì)協(xié)作平臺，可以無縫整合軟件與系統(tǒng)開發(fā)生命周期中的工作。Jazz旨在推動(dòng)廣大軟件開發(fā)人員考慮摒棄單人開發(fā)工具，轉(zhuǎn)而采用多人協(xié)作開發(fā)工具，以實(shí)現(xiàn)各人員間步調(diào)更一致的溝通與協(xié)作。Jazz 使用一種名為“開放商業(yè)軟件開發(fā)”的新形式進(jìn)行開發(fā)。Jazz 的開發(fā)工作在 Jazz.net 以開放的方式進(jìn)行。這種開放性和透明性的好處在于，它允許客戶成為持續(xù)反饋循環(huán)的一部分，以便推動(dòng)開發(fā)決策。您可以通過 Jazz.net 了解開發(fā)工作的進(jìn)展情況。

2.4.3? ?GitLab

雖然Microsoft Azure DevOps和IBM Jazz都是重要的DevOps平臺，功能也很強(qiáng)大，但兩套系統(tǒng)并不兼容，不能選擇這兩個(gè)平臺作為開發(fā)和代碼管控平臺。主要的原因如下：

（1）系統(tǒng)過于復(fù)雜，模塊過多，軟件開發(fā)者和使用者都不容易掌握，如果要使用這些系統(tǒng)，會付出高昂的培訓(xùn)費(fèi)用。

（2）不能在本公司內(nèi)部搭建Azure DevOps和IDB Jazz平臺，有代碼泄露的風(fēng)險(xiǎn)。

（3）使用成本高。兩個(gè)系統(tǒng)都需要支付用戶費(fèi)用。以Azure DevOps為例，Azure DevOps對于開源項(xiàng)目和小項(xiàng)目（最多五個(gè)用戶）是免費(fèi)的。但是對于大型團(tuán)隊(duì)，費(fèi)用從每月30美元（10個(gè)用戶）到每月6 150美元（1 000個(gè)用戶）。

綜上所述，必須要選擇可靠、易用、費(fèi)用低廉并且能自我維護(hù)的代碼管控平臺[3]。根據(jù)前期評估。選擇GitLab作為代碼管控平臺[2]。最主要的理由就是GitLab支持企業(yè)內(nèi)部自主搭建，功能全面，成熟。

GitLab是一款免費(fèi)的、開源的、分布式的版本控制系統(tǒng)。旨在快速高效地處理無論規(guī)模大小的任何軟件工程。每一個(gè) Git克隆都是一個(gè)完整的文件庫，含有全部歷史記錄和修訂追蹤能力，不依賴于網(wǎng)絡(luò)連接或中心服務(wù)器。其最大特色就是“分支”及“合并”操作非?？焖佟⒑啽?。GitLab 是一個(gè)用于倉庫管理系統(tǒng)的開源項(xiàng)目，使用Git作為代碼管理工具，并在此基礎(chǔ)上搭建起來的Web服務(wù)。Gitlab是一個(gè)用Ruby on Rails開發(fā)的開源項(xiàng)目管理程序，可以通過WEB界面進(jìn)行訪問公開的或者私人項(xiàng)目。它能夠?yàn)g覽源代碼，管理缺陷和注釋。GitLab具有完整的分支管理和用戶管理功能，能夠完成各種項(xiàng)目的源代碼及版本的管控。其核心功能包括：

（1）軟件項(xiàng)目（資料庫）管理;

（2）標(biāo)簽管理;

（3）分配成員角色;

（4）鎖定受保護(hù)的分支;

（5）發(fā)起、審查、處理合并請求;

（6）代碼評論;

（7）代碼片段管理;

（8）郵件通知;

（9）持續(xù)集成。

除此之外，GitLab還是一個(gè)開源系統(tǒng)，開發(fā)接口，允許第三方軟件接入。目采用GitLab可以很方便地將本公司內(nèi)部的管理人員與第三方軟件公司的程序人員整合在一個(gè)平臺上，各自扮演自己的角色，最后完成代碼成果規(guī)范、代碼成果入庫質(zhì)量評審、檢測、代碼成果存儲、運(yùn)維以及代碼成果出庫等既定目標(biāo)的工作。

3? ? ? 代碼成果管控系統(tǒng)設(shè)計(jì)實(shí)現(xiàn)

基于GitLab代碼庫構(gòu)建代碼成果管控系統(tǒng)，整個(gè)系統(tǒng)由代碼項(xiàng)目服務(wù)、代碼庫服務(wù)、代碼評審服務(wù)3個(gè)關(guān)鍵服務(wù)構(gòu)成。

3.1? ?系統(tǒng)整體架構(gòu)

系統(tǒng)整體架構(gòu)如圖2所示。

3.2? ?基礎(chǔ)服務(wù)體系

3.2.1? ?用戶

用戶管理模塊提供對用戶信息的管理，包括用戶注冊、用戶登錄、用戶權(quán)限管理、用戶信息修改以及用戶等級修改。

3.2.2? ?日志

一個(gè)合格的系統(tǒng)不僅僅要求具有運(yùn)行的高效和計(jì)算的準(zhǔn)確，同時(shí)又必須兼顧穩(wěn)定性、可靠性。其次，對于開發(fā)人員來說，又必須具有可拓展性和可維護(hù)性。為了快速、準(zhǔn)確地對bug進(jìn)行定位分析和解決，在系統(tǒng)設(shè)計(jì)、開發(fā)和實(shí)現(xiàn)的過程中必須注意日志的記錄，這將會對于日后的系統(tǒng)監(jiān)控和異常分析起至關(guān)重要的作用。

3.2.3? ?權(quán)限

權(quán)限管理進(jìn)行權(quán)限檢測，讓經(jīng)過授權(quán)的用戶可以正常合法的使用已授權(quán)的功能，而對那些未授權(quán)的非法用戶拒之門外。權(quán)限管理對于代碼成果管控系統(tǒng)至關(guān)重要。由于代碼是企業(yè)的核心資產(chǎn)和商業(yè)機(jī)密，不能透露給非授權(quán)用戶，因此要對用戶進(jìn)行授權(quán)、鑒權(quán)，保證未授權(quán)用戶不能接觸到相關(guān)內(nèi)容。

3.2.4? ?動(dòng)態(tài)表單

動(dòng)態(tài)表單是用拖拽的方式創(chuàng)建表單，到指派對應(yīng)的工作流，再到表單的使用和歸檔的一整套功能。創(chuàng)建好的表單可以分類保存，使用者可以重用它們。

動(dòng)態(tài)表單的目的是為了根據(jù)業(yè)務(wù)流程不同靈活設(shè)計(jì)顯示頁面，在業(yè)務(wù)流程設(shè)計(jì)階段不用過多地考慮表單如何實(shí)現(xiàn)，將業(yè)務(wù)流程與表單顯示分離開了，充分體現(xiàn)了系統(tǒng)的靈活性。

3.2.5? ?流程引擎

流程引擎作為應(yīng)用系統(tǒng)的一部分，并為之提供對各應(yīng)用系統(tǒng)有決定作用的根據(jù)角色、分工和條件的不同決定信息傳遞路由、內(nèi)容等級等核心解決方案。流程引擎包括流程的節(jié)點(diǎn)管理、流向管理、流程樣例管理等重要功能。

3.2.6? ?消息通知

為了讓用戶獲得需要得到的消息及提醒并進(jìn)行處理，如處理工作流中的審批、用戶彼此互動(dòng)觸發(fā)的信息流（留言、評論或者回復(fù)、私信等）、系統(tǒng)希望用戶了解關(guān)注的信息（系統(tǒng)公告等）等相關(guān)信息，通過特定的通知渠道（郵件、短信、站內(nèi)消息等），將消息內(nèi)容發(fā)送到特定的用戶。

3.2.7? ?附件

在代碼管控的過程中，作為系統(tǒng)的必要補(bǔ)充，用戶將會上傳例如：需求規(guī)程說明書、詳細(xì)設(shè)計(jì)說明書、用戶手冊等相關(guān)內(nèi)容，這些內(nèi)容作為附件與系統(tǒng)代碼一起統(tǒng)一管理。因此，附件模塊提供文件上傳、下載、刪除等相關(guān)功能。

3.2.8? ?GitLab

GitLab是代碼成果管控系統(tǒng)最基礎(chǔ)、最核心的功能，所有的代碼都存儲在GitLab中。GitLab具有完整的分支管理和用戶管理功能，能夠完成各種項(xiàng)目的源代碼及版本的管控。

3.2.9? ?LADP

輕型目錄訪問協(xié)議（LDAP）是一個(gè)開放的，中立的，工業(yè)標(biāo)準(zhǔn)的應(yīng)用協(xié)議，通過IP協(xié)議提供訪問控制和維護(hù)分布式信息的目錄信息。目錄服務(wù)在開發(fā)內(nèi)部網(wǎng)和與互聯(lián)網(wǎng)程序共享用戶、系統(tǒng)、網(wǎng)絡(luò)、服務(wù)和應(yīng)用的過程中占據(jù)了重要地位。

3.3? ?代碼庫服務(wù)

代碼庫服務(wù)提供以Git為基礎(chǔ)的日常開發(fā)源代碼版本管理，包括代碼瀏覽、分？管理、發(fā)布管理、版本對比、合并請求、項(xiàng)？？絡(luò)等，提供強(qiáng)于Git 的代碼管理使用體驗(yàn)。

在對代碼進(jìn)行管理時(shí)，需要對代碼分支管理做一定規(guī)范，將GitLab劃分四種分支，dev，test，master，hotfix。將四種分支分屬開發(fā)，測試，主干、修復(fù)四個(gè)角色進(jìn)行管理。

3.3.1? ?開發(fā)（dev）

開發(fā)人員將功能分支代碼合并到dev分支后，觸發(fā)構(gòu)建過程，代碼打包，鏡像構(gòu)建等，完成構(gòu)建后，通過容器管理平臺將新構(gòu)建的鏡像進(jìn)行發(fā)布。

3.3.2? ?測試（test）

當(dāng)開發(fā)人員將代碼交付測試部門時(shí)，測試人員，將代碼merge到test分支中，此時(shí)觸發(fā)測試分支的構(gòu)建的流程，完成構(gòu)建后，通過管理平臺進(jìn)行測試環(huán)境的發(fā)布。

3.3.3? ?主干（master）

測試驗(yàn)收通過后，交付運(yùn)維團(tuán)隊(duì)進(jìn)行上線升級，將代碼合并到master分支中，構(gòu)建release版本信息，構(gòu)建完成后，發(fā)布應(yīng)用。

3.3.4? ?問題修改（hotfix）

用于修復(fù)線上問題，從對應(yīng)線上版本的拉取，修改并測試完成后合并到master，在master測試完成后，從master發(fā)布

3.4? ?項(xiàng)目服務(wù)

3.4.1? ?創(chuàng)建項(xiàng)目

每個(gè)項(xiàng)目都有屬于它自己的相應(yīng)代碼，所以在管理代碼之前，應(yīng)該先建立相應(yīng)的項(xiàng)目信息。建立好項(xiàng)目之后，才能將代碼倉庫與項(xiàng)目進(jìn)行關(guān)聯(lián)。

3.4.2? ?項(xiàng)目管理

項(xiàng)目管理模塊對項(xiàng)目的詳細(xì)信息進(jìn)行編輯修改，維護(hù)項(xiàng)目資料，以及由管理員決定啟用或禁用該項(xiàng)目，以管理項(xiàng)目從建立到結(jié)束作為整個(gè)生命周期。

3.4.3? ?版本管理

所有系統(tǒng)開發(fā)及實(shí)施項(xiàng)目的軟件項(xiàng)目都應(yīng)進(jìn)行版本管理。項(xiàng)目中所有正式文檔和代碼都應(yīng)納入配置庫進(jìn)行版本管理，確保版本的準(zhǔn)確性和可追溯性。

3.4.4? ?代碼庫

代碼庫應(yīng)歸屬于某個(gè)項(xiàng)目，不應(yīng)該單獨(dú)存在，并且1個(gè)項(xiàng)目可能包括0或多個(gè)代碼庫。用戶通過代碼庫模塊，直接管理和維護(hù)位于GitLab上的代碼倉庫。

3.5? ?評審服務(wù)

軟件測試本身有一定的局限性，在檢測軟件缺陷中，單元測試發(fā)現(xiàn)缺陷的比例大概是25%，功能測試占到35%，集成測試占到45%。相比之下，設(shè)計(jì)和代碼審查的效率要高很多，發(fā)現(xiàn)缺陷的比例可以達(dá)到55%-60%。對審查結(jié)果的案例學(xué)習(xí)對項(xiàng)目的幫助也非常大。

3.5.1? ?缺陷分類

預(yù)先建立缺陷分類，如：需求錯(cuò)誤、命名不規(guī)范、性能不足等，方便在代碼評審?fù)瓿芍筮M(jìn)行相關(guān)檢索，快速定位缺陷。

3.5.2? ?缺陷記錄

對在代碼評審過程中發(fā)現(xiàn)的問題，記錄到系統(tǒng)之中，形成記錄，并指派給相應(yīng)責(zé)任人，避免評審的形式主義，確保每個(gè)缺陷都有人負(fù)責(zé)。

3.5.3? ?統(tǒng)計(jì)分析

對評審出來的缺陷進(jìn)行統(tǒng)計(jì)分析，形成報(bào)表，以此對開發(fā)人員或供應(yīng)商進(jìn)行評估，分析他們的能力，為后續(xù)的工作提供數(shù)據(jù)支撐。

3.6? ?用戶服務(wù)

3.6.1? ?開發(fā)者

開發(fā)者是要審查的代碼的作者，負(fù)責(zé)代碼的編寫、調(diào)試，以及Bug的修改。

3.6.2? ?供應(yīng)商

供應(yīng)商是代碼的所有者，并且也是發(fā)起審查活動(dòng)的人。

3.6.3? ?審查者

審查者是審查代碼并且要報(bào)告審查結(jié)果給開發(fā)者和供應(yīng)商的人。

4? ? ? 方案測試

為了驗(yàn)證本文提出的代碼成果管控功能的可行性和可靠性，開發(fā)了一套代碼陳成果管控系統(tǒng)，參照K8S+docker架構(gòu)搭建了系統(tǒng)，對某企業(yè)四個(gè)應(yīng)用系統(tǒng)進(jìn)行代碼入庫與代碼編譯驗(yàn)證、系統(tǒng)部署測試、系統(tǒng)安全測評工作。代碼編譯驗(yàn)證和系統(tǒng)部署測試平均所用時(shí)間由2天左右縮短為1天左右，系統(tǒng)安全測評時(shí)間由10天縮短為6天左右。經(jīng)測算，同等測試工作量下，測評效率提高40%左右。同時(shí)代碼相關(guān)資料完整性從原來的75%上升到95%。

5? ? ? 結(jié)? ? 語

通過測試證明，代碼成果管控系統(tǒng)可有效管控企業(yè)軟件開發(fā)形成的各類代碼成果，并可進(jìn)行代碼安全分發(fā)，支持系統(tǒng)的持續(xù)開發(fā)與持續(xù)集成。使得軟件系統(tǒng)的構(gòu)建、測試、發(fā)布更加快捷、頻繁和可靠。

主要參考文獻(xiàn)

[1]汪佩華.軟件開發(fā)團(tuán)隊(duì)中代碼管理和版本控制[J].計(jì)算機(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能力模型的持續(xù)集成方法[J].計(jì)算機(jī)工程與設(shè)計(jì)，2018，39（7）：1930-1937.