基于DevOps的軟件配置項管理

屠趁鋒

摘 要：文章簡述了DevOps概念，基于DevOps的配置項管理相關活動，通過規范化管理配置項，從而實現DevOps能更好與敏捷開發、TDD、微服務化、Cloud Native等相互配合與協作，最終實現高質量的快速交付產品及版本的頻繁部署。

關鍵詞：DevOps；配置項管理；軟件配置管理

近幾年，在互聯網行業、軟件行業DevOps理念成了一種趨勢。DevOps是一種理念，倡導無縫協作和流水線自動化，它與敏捷開發、微服務化、Cloud Native等相互配合與協作，最終的目標是實現高質量的快速交付及頻繁的版本部署。

軟件配置管理（Software Configuration Management，SCM），是一套規范、高效的軟件開發基礎結構。作為管理軟件開發過程有效的方法，它早已被軟件產業的發展和實踐所證明。SCM通過系統地管理軟件系統中的各配置項；并全面記載配置項的演進歷史過程，包括配置項命名規范、為什么修改，誰作了修改，修改了什么；管理和追蹤開發過程中危害軟件質量以及影響開發周期的缺陷和變化。配置項（Configuration Item，CI），是配置管理指定的工作產品的一個集合，在配置管理過程中看作一個單一實體。研發和管理過程中產生的工作產品，是配置管理基本的單元。軟件配置管理在研發體系中發揮重要作用的主要體現，是在對配置項的規范管理上[1]。

為了更好地服務于DevOps模式的軟件配置管理工作，岌待一套規范完整且適用于產品研發、項目實施的配置項管理活動。

1 基于DevOps的軟件配置項管理

DevOps加快了構建、發布、部署的速度，為了達到這種快捷，通過工具實現自動化成了必然，需要工具做的操作，就必須要有一套工具能識別的信息輸入規范，所以組成產品的配置項迫切需要有一套規范化的管理機制，成為軟件配置管理活動中重要的組成部分[2]。

1.1 配置管理工具

互聯網行業和軟件行業的軟件配置項一般存儲在SVN或GIT等版本管理工具上。以筆者所在公司為例，我們使用SVN管理源代碼、文檔、SQL腳本、配置文件等配置項。配置庫的目錄結構劃分及命名，都有具體的規范要求，舉例說明：

branches：存放正在演進中的源代碼

script：存放SQL腳本

tags：存放里程牌的產品基線

trunk： 存放需要發布熱補的產品基線

1.2 配置項命名規范

軟件產品包含的配置項一般由源代碼文件、文檔、鏡像文件（傳統模式稱二進制文件）、SQL腳本、配置文件等組成。以我公司為例，在推行DevOps模式之前，我們制定了一套配置項名稱規范，通過約束條件，讓工具識別它、運行它，實現更多操作的自動化。

1.2.1 源代碼文件

源代碼文件標識，按模塊實現的功能命名。

例如：賬務管理的源碼存放在payment目錄；服務開通的源碼存放在prov目錄。

1.2.2 文檔文件

文檔標識，由“產品名稱”“文檔代號”“版本號”3部分組成，產品名稱和文檔代號之間以下劃線分隔。

（1）產品名稱：規劃部門輸出標準名稱，產品名稱統一用英文小寫。（2）文檔代號：D。（3）版本號：從1開始按順序+1遞增。

例如：CRM_D1.0—這代表crm產品1.0版本的文檔。

1.2.3 鏡像文件

鏡像文件標識，由“產品名稱”“進程名”“制作日期”“歸屬名稱”4部分組成，每項之間用下劃線分隔。

（1）產品名稱：規劃部門輸出標準名稱，產品名稱統一用英文小寫。（2）進程名：業務應用簡稱。（3）歸屬名稱：public、project；public代表是公用產品鏡像文件，project是某項目專用產品鏡像文件，例如：南京項目project為nanjing。（4）制作日期：由數字標識，即當前制作鏡像的時間。

例如：crm_app_public：CD_20180716212907—這代表crm產品app進程在2018.07.16.21.29.07時生成的公用鏡像文件。

crm_api_nanjing：CD_20180726212808—這代表crm產品api進程在2018.07.26.21.28.08時生成的南京項目專用鏡像文件。

鏡像后綴CD_20180716212907用來區分鏡像文件，CD流程構建默認為CD_{$datetime}，例如：CD_20180712123405，時間為構建時間。

CI流程構建默認為CI_{$datetime}，例如：CI_20180812123405，時間為構建時間。

1.2.4 配置文件

配置文件標識，由“產品名稱”“進程名”“配置標志符”“歸屬名稱”4部分組成，每項之間用減號分隔。

（1）產品名稱：規劃部門輸出標準名稱，產品名稱統一用英文小寫。（2）進程名：業務應用簡稱。（3）配置標識符：config。（4）歸屬名稱：public、project；public代表是公用產品配置文件，project是某項目專用產品配置文件，譬如，杭州項目project為hangzhou。

例如：crm-app-config-public這代表是crm產品app公用的進程配置文件。

crm-api-config-hangzhou這代表是crm產品api杭州項目的進程配置文件。

1.2.5 全量SQL文件

全量建表腳本標識由“產品名稱”“進程名”“數據庫用戶名”“數據庫類型”4部分組成，中間用下劃線分隔，名稱統一使用小寫。

（1）產品名稱：規劃部門輸出標準名稱，產品名稱統一用英文小寫。（2）進程名：業務應用簡稱。（3）數據庫用戶名：cc＼rb 等。（4）數據庫類型：oracle＼mysql等。

例如：crm_app_cc_oracle.sql—這代表crm產品APP業務應用需要在oracle數據庫cc數據庫用戶下執行的腳本。

1.2.6 熱補增量SQL文件

熱補的增量腳本標識是在產品熱補標識的基礎上，后面加在“數據庫用戶名”“數據庫類型”組成。

（1）產品熱補號：CRM_R1.0.1。（2）數據庫用戶名：cc＼rb等。（3）數據庫類型：oracle＼mysql等。

例如：CRM_R1.0.1_cc_oracle.sql—這代表crm產品1.0.1產品熱補需要在oracle數據庫cc數據庫用戶下執行的腳本。

1.3 配置項控制

1.3.1 流程描述

（1）提交變更。根據不同配置項的命名，配置管理員會為每種配置項增加對應的變更類型并對每個變更申請賦予唯一標識，研發人員可以根據需要變更的配置項提交變更申請，配置管理員根據申請，檢查變更的完整性和明確性，如果配置管理員認為申請變更描述不夠完整，可以打回提交者重新提交。

（2）審核變更申請。需要對變更申請進行初步審核，如果確認是bug則直接轉配置管理員授修改權限，進行修改、測試、發布，如果是需求需要提交軟件變更控制委員會（Software Change Control Board，SCCB）審核。

（3）變更評估和分派。SCCB需要對變更申請進行充分的分析評估，涉及對系統性能、接口、可用性、成本、進度、需求的引用原因評估，通過評審后派發給研發人員修改。

（4）變更實施。變更人員需要獲取必須的資源，由配置管理員從配置庫中獲取需要變更的配置項的正式版本，提交變更人員。對代碼的修改涉及設計、編碼、驗證的過程，并且所有相關干系人需要對可能受到影響的文檔進行更新。

（5）變更驗證及入庫。對已變更過的配置項，需要啟動單元測試或自動化測試的驗證，驗證后才允許提交配置庫。

1.3.2 輸入

研發人員提供變更申請，申請通過后，可以對配置項進行修改，修改過程中嚴格按照配置項規范操作。

1.3.3 輸出

提交經過自動化構建、測試，可供發布的軟件配置項入庫，配置管理員為變更后的配置項建立的新基線，隨時可發布客戶運維部署。

具體流程如圖1所示。

2 結語

隨著DevOps的進一步推廣，研發流程對工具自動化要求的提高，灰度發布將成為主流，從而對軟件中各種配置項的規范要求也會更高。所以正確地采用、實施規范的配置項，必將提高研發流程各環節的生產力，增強對整個項目的控制，改善軟件產品的質量及交付速度。

[參考文獻]

[1]珍妮佛，戴維斯，萊恩，等.Effective DevOps： building a culture of collaboration， affinity， and tooling at scale[M].北京：中國電力出版社，2018.

[2]倫恩·拜斯，英戈·韋伯，朱黎明.DevOps：軟件架構師行動指南[M].北京：機械工業出版社，2017.

Abstract：This paper briefly describes the DevOps concept， based on DevOps configuration item management related activities， through the standardized management configuration items， so that DevOps can better cooperate with agile development， TDD， micro-service， Cloud Native， etc.， and finally achieve high-quality， fast delivery products and frequent deployments of versions.

Key words：DevOps； configuration item management； software configuration management