一種企業代碼成果管控系統的設計研究

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

[摘? ? 要] 對于軟件項目來講，整個項目的投入最終的知識成果累積核心就在最后交付的成果代碼和文檔，此成果承載著企業的生產管理業務邏輯以及算法經驗，是軟件項目最重要的資產。對于最重要的成果之一，但企業往往只重視代碼編譯生成的軟件應用，缺少對代碼的質量評測，同時代碼成果入庫及出庫的隨機性導致軟件知識成果大量流失，沒有代碼、低品質代碼，代碼作為個人或開發單位的私產被保存的情況大量存在。導致軟件持續開發、集成困難，重復開發、代碼丟失、代碼缺陷等問題突出。按照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.