屠趁鋒

摘 要：文章簡述了DevOps概念，基于DevOps的配置項(xiàng)管理相關(guān)活動，通過規(guī)范化管理配置項(xiàng)，從而實(shí)現(xiàn)DevOps能更好與敏捷開發(fā)、TDD、微服務(wù)化、Cloud Native等相互配合與協(xié)作，最終實(shí)現(xiàn)高質(zhì)量的快速交付產(chǎn)品及版本的頻繁部署。

關(guān)鍵詞：DevOps；配置項(xiàng)管理；軟件配置管理

近幾年，在互聯(lián)網(wǎng)行業(yè)、軟件行業(yè)DevOps理念成了一種趨勢。DevOps是一種理念，倡導(dǎo)無縫協(xié)作和流水線自動化，它與敏捷開發(fā)、微服務(wù)化、Cloud Native等相互配合與協(xié)作，最終的目標(biāo)是實(shí)現(xiàn)高質(zhì)量的快速交付及頻繁的版本部署。

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

為了更好地服務(wù)于DevOps模式的軟件配置管理工作，岌待一套規(guī)范完整且適用于產(chǎn)品研發(fā)、項(xiàng)目實(shí)施的配置項(xiàng)管理活動。

1 基于DevOps的軟件配置項(xiàng)管理

DevOps加快了構(gòu)建、發(fā)布、部署的速度，為了達(dá)到這種快捷，通過工具實(shí)現(xiàn)自動化成了必然，需要工具做的操作，就必須要有一套工具能識別的信息輸入規(guī)范，所以組成產(chǎn)品的配置項(xiàng)迫切需要有一套規(guī)范化的管理機(jī)制，成為軟件配置管理活動中重要的組成部分[2]。

1.1 配置管理工具

互聯(lián)網(wǎng)行業(yè)和軟件行業(yè)的軟件配置項(xiàng)一般存儲在SVN或GIT等版本管理工具上。以筆者所在公司為例，我們使用SVN管理源代碼、文檔、SQL腳本、配置文件等配置項(xiàng)。配置庫的目錄結(jié)構(gòu)劃分及命名，都有具體的規(guī)范要求，舉例說明：

branches：存放正在演進(jìn)中的源代碼

script：存放SQL腳本

tags：存放里程牌的產(chǎn)品基線

trunk： 存放需要發(fā)布熱補(bǔ)的產(chǎn)品基線

1.2 配置項(xiàng)命名規(guī)范

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

1.2.1 源代碼文件

源代碼文件標(biāo)識，按模塊實(shí)現(xiàn)的功能命名。

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

1.2.2 文檔文件

文檔標(biāo)識，由“產(chǎn)品名稱”“文檔代號”“版本號”3部分組成，產(chǎn)品名稱和文檔代號之間以下劃線分隔。

（1）產(chǎn)品名稱：規(guī)劃部門輸出標(biāo)準(zhǔn)名稱，產(chǎn)品名稱統(tǒng)一用英文小寫。（2）文檔代號：D。（3）版本號：從1開始按順序+1遞增。

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

1.2.3 鏡像文件

鏡像文件標(biāo)識，由“產(chǎn)品名稱”“進(jìn)程名”“制作日期”“歸屬名稱”4部分組成，每項(xiàng)之間用下劃線分隔。

（1）產(chǎn)品名稱：規(guī)劃部門輸出標(biāo)準(zhǔn)名稱，產(chǎn)品名稱統(tǒng)一用英文小寫。（2）進(jìn)程名：業(yè)務(wù)應(yīng)用簡稱。（3）歸屬名稱：public、project；public代表是公用產(chǎn)品鏡像文件，project是某項(xiàng)目專用產(chǎn)品鏡像文件，例如：南京項(xiàng)目project為nanjing。（4）制作日期：由數(shù)字標(biāo)識，即當(dāng)前制作鏡像的時間。

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

crm_api_nanjing：CD_20180726212808—這代表crm產(chǎn)品api進(jìn)程在2018.07.26.21.28.08時生成的南京項(xiàng)目專用鏡像文件。

鏡像后綴CD_20180716212907用來區(qū)分鏡像文件，CD流程構(gòu)建默認(rèn)為CD_{$datetime}，例如：CD_20180712123405，時間為構(gòu)建時間。

CI流程構(gòu)建默認(rèn)為CI_{$datetime}，例如：CI_20180812123405，時間為構(gòu)建時間。

1.2.4 配置文件

配置文件標(biāo)識，由“產(chǎn)品名稱”“進(jìn)程名”“配置標(biāo)志符”“歸屬名稱”4部分組成，每項(xiàng)之間用減號分隔。

（1）產(chǎn)品名稱：規(guī)劃部門輸出標(biāo)準(zhǔn)名稱，產(chǎn)品名稱統(tǒng)一用英文小寫。（2）進(jìn)程名：業(yè)務(wù)應(yīng)用簡稱。（3）配置標(biāo)識符：config。（4）歸屬名稱：public、project；public代表是公用產(chǎn)品配置文件，project是某項(xiàng)目專用產(chǎn)品配置文件，譬如，杭州項(xiàng)目project為hangzhou。

例如：crm-app-config-public這代表是crm產(chǎn)品app公用的進(jìn)程配置文件。

crm-api-config-hangzhou這代表是crm產(chǎn)品api杭州項(xiàng)目的進(jìn)程配置文件。

1.2.5 全量SQL文件

全量建表腳本標(biāo)識由“產(chǎn)品名稱”“進(jìn)程名”“數(shù)據(jù)庫用戶名”“數(shù)據(jù)庫類型”4部分組成，中間用下劃線分隔，名稱統(tǒng)一使用小寫。

（1）產(chǎn)品名稱：規(guī)劃部門輸出標(biāo)準(zhǔn)名稱，產(chǎn)品名稱統(tǒng)一用英文小寫。（2）進(jìn)程名：業(yè)務(wù)應(yīng)用簡稱。（3）數(shù)據(jù)庫用戶名：cc＼rb 等。（4）數(shù)據(jù)庫類型：oracle＼mysql等。

例如：crm_app_cc_oracle.sql—這代表crm產(chǎn)品APP業(yè)務(wù)應(yīng)用需要在oracle數(shù)據(jù)庫cc數(shù)據(jù)庫用戶下執(zhí)行的腳本。

1.2.6 熱補(bǔ)增量SQL文件

熱補(bǔ)的增量腳本標(biāo)識是在產(chǎn)品熱補(bǔ)標(biāo)識的基礎(chǔ)上，后面加在“數(shù)據(jù)庫用戶名”“數(shù)據(jù)庫類型”組成。

（1）產(chǎn)品熱補(bǔ)號：CRM_R1.0.1。（2）數(shù)據(jù)庫用戶名：cc＼rb等。（3）數(shù)據(jù)庫類型：oracle＼mysql等。

例如：CRM_R1.0.1_cc_oracle.sql—這代表crm產(chǎn)品1.0.1產(chǎn)品熱補(bǔ)需要在oracle數(shù)據(jù)庫cc數(shù)據(jù)庫用戶下執(zhí)行的腳本。

1.3 配置項(xiàng)控制

1.3.1 流程描述

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

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

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

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

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

1.3.2 輸入

研發(fā)人員提供變更申請，申請通過后，可以對配置項(xiàng)進(jìn)行修改，修改過程中嚴(yán)格按照配置項(xiàng)規(guī)范操作。

1.3.3 輸出

提交經(jīng)過自動化構(gòu)建、測試，可供發(fā)布的軟件配置項(xiàng)入庫，配置管理員為變更后的配置項(xiàng)建立的新基線，隨時可發(fā)布客戶運(yùn)維部署。

具體流程如圖1所示。

2 結(jié)語

隨著DevOps的進(jìn)一步推廣，研發(fā)流程對工具自動化要求的提高，灰度發(fā)布將成為主流，從而對軟件中各種配置項(xiàng)的規(guī)范要求也會更高。所以正確地采用、實(shí)施規(guī)范的配置項(xiàng)，必將提高研發(fā)流程各環(huán)節(jié)的生產(chǎn)力，增強(qiáng)對整個項(xiàng)目的控制，改善軟件產(chǎn)品的質(zhì)量及交付速度。

[參考文獻(xiàn)]

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

[2]倫恩·拜斯，英戈·韋伯，朱黎明.DevOps：軟件架構(gòu)師行動指南[M].北京：機(jī)械工業(yè)出版社，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