配置管理規(guī)范

文件編碼文件密級(jí)最新發(fā)布日期當(dāng)前版本XX軟件股份有限公司配置管理規(guī)范鄭重聲明：XX軟件股份有限公司版權(quán)所有。本文檔中任何部分未經(jīng)XX軟件股份有限公司書(shū)面授權(quán)，不得將材料泄露給第三方，不得以任何手段、任何形式進(jìn)行復(fù)制與傳播。變更履歷版本日期變更位置變更理由/變更內(nèi)容變更人備注1.0新建，將原配置管理規(guī)范、OSSP中的配置管理規(guī)程進(jìn)行整合，并結(jié)合目前公司要求。

目錄1 概述 22 術(shù)語(yǔ)定義 23 適用范圍 34 閱讀對(duì)象 35 配置管理計(jì)劃 35.1 配置管理計(jì)劃流程圖 45.2 配置管理計(jì)劃流程說(shuō)明 46 配置管理軟硬件資源確定 56.1 配置管理服務(wù)器 56.2 配置管理工具 67 配置項(xiàng)/文檔管理 77.1 配置項(xiàng)識(shí)別 77.2 配置項(xiàng)編寫及命名 87.3 配置項(xiàng)入庫(kù) 88 配置庫(kù)目錄結(jié)構(gòu)規(guī)劃 89 權(quán)限管理 99.1 用戶角色定義 99.2 配置庫(kù)操作定義 109.3 配置庫(kù)授權(quán)控制參考 109.4 注意事項(xiàng) 1010 基線管理 1110.1 基線計(jì)劃制定 1110.2 基線建立時(shí)機(jī) 1110.3 基線建立流程 1210.4 基線命名規(guī)范 1311 分支合并管理 1311.1 分支建立 1411.1.1 分支建立時(shí)機(jī) 1411.1.2 分支建立模式 1411.2 分支合并 1411.2.1 分支合并類型 1411.2.2 版本庫(kù)發(fā)布模式 1512 代碼集成管理 1513 發(fā)布管理 1613.1 正式版本發(fā)布 1613.2 測(cè)試版本發(fā)布 1713.3 臨時(shí)版本發(fā)布 1714 變更管理 1814.1 變更控制 1814.2 變更流程 1914.3 變更結(jié)束準(zhǔn)則 2015 備份/還原管理 2016 生效 2017 參考及附錄 20

概述配置管理（CM）的目的是協(xié)調(diào)軟件開(kāi)發(fā)過(guò)程、對(duì)項(xiàng)目生命周期過(guò)程中各種階段產(chǎn)品的演化和變更進(jìn)行管理、使混亂（一旦發(fā)生，其代價(jià)通常都很大）減至最小，從而保證軟件工作產(chǎn)品的一致性和完整性。從變更的意義講，配置管理要解決變更標(biāo)識(shí)、變更控制以及變更發(fā)布的問(wèn)題。配置管理是項(xiàng)目質(zhì)量管理的重要組成部分，在控制由多人參與項(xiàng)目所生成的大量工作產(chǎn)品時(shí)，配置管理過(guò)程規(guī)范化至關(guān)重要。本文檔的編寫目的是統(tǒng)一軟件配置管理規(guī)范，為配置管理活動(dòng)提供指導(dǎo)。配置管理活動(dòng)主要遵循以下原則：受控：公司所有產(chǎn)品/項(xiàng)目產(chǎn)生的所有工作成果（即信息資產(chǎn)，也體現(xiàn)為配置項(xiàng)）都必須納入公司統(tǒng)一管理之下，并接受公司級(jí)配置管理的監(jiān)控。安全：所有工作成果都必須存放在配置庫(kù)，配置庫(kù)需配備相應(yīng)的安全管理措施，包括訪問(wèn)控制、備份/還原等。一致：所有工作成果各階段版本都應(yīng)該提交到配置庫(kù)中，而且其內(nèi)容是一致的，比如工作成果中參考或引用的其他工作成果的正確版本是否存在配置庫(kù)中或者是否提供了訪問(wèn)鏈接。完整：配置庫(kù)中存放的工作成果應(yīng)該包含產(chǎn)品/項(xiàng)目組全體成員為此項(xiàng)目完成的全部工作成果；要求能夠基于配置庫(kù)的最新內(nèi)容隨時(shí)構(gòu)建無(wú)損發(fā)布包（包括程序代碼、可執(zhí)行程序和相關(guān)文檔資料）。及時(shí)：立項(xiàng)產(chǎn)品/項(xiàng)目各項(xiàng)工作成果的新建或修訂均應(yīng)該及時(shí)納入配置庫(kù)。未立項(xiàng)產(chǎn)品/項(xiàng)目的文檔應(yīng)及時(shí)納入公司專門的服務(wù)器中。術(shù)語(yǔ)定義No.術(shù)語(yǔ)定義1配置管理（CM）配置管理是對(duì)項(xiàng)目生命周期過(guò)程中各階段產(chǎn)品和最終產(chǎn)品演化和變更的管理，是質(zhì)量管理的重要組成部分。配置管理通過(guò)一系列技術(shù)、方法和手段實(shí)現(xiàn)：指導(dǎo)和監(jiān)督對(duì)配置項(xiàng)的物理與功能特性的標(biāo)識(shí)和歸檔工作。控制上述特性的變更，記錄并報(bào)告變更的處理和實(shí)現(xiàn)狀態(tài)，并驗(yàn)證與需求的一致性。2變更控制委員會(huì)（CCB）CCB是一個(gè)虛擬小組，由項(xiàng)目監(jiān)理小組、項(xiàng)目經(jīng)理、資深項(xiàng)目成員、配置管理員、品質(zhì)保證工程師等組成，項(xiàng)目經(jīng)理為CCB召集人；CCB對(duì)配置管理各項(xiàng)活動(dòng)擁有決策權(quán)（例如評(píng)審計(jì)劃、評(píng)審變更請(qǐng)求等），負(fù)責(zé)評(píng)估和審批配置項(xiàng)的變更、確保所有的變更都是經(jīng)過(guò)審核的。3配置項(xiàng)（ConfigurationItem,CI）配置項(xiàng)是指納入配置管理范疇的工作成果的最小集合。例如一個(gè)文檔（如需求文檔、設(shè)計(jì)文檔、測(cè)試用例、用戶文檔等屬于產(chǎn)品組成部分的工作成果以及項(xiàng)目管理、組織支撐過(guò)程域產(chǎn)生的文檔）或一組構(gòu)成獨(dú)立功能單元的源代碼文件都可以定義為一個(gè)配置項(xiàng)。4基線（Baseline）基線由一組穩(wěn)定的特定版本的配置項(xiàng)組成，是進(jìn)一步開(kāi)發(fā)的基礎(chǔ)。基線中的配置項(xiàng)是被“凍結(jié)”的，不能被隨意修改?；€通常在開(kāi)發(fā)過(guò)程中的里程碑（Milestone）處建立，一般包括需求基線、設(shè)計(jì)基線、開(kāi)發(fā)基線、發(fā)版基線、結(jié)項(xiàng)基線等。5配置管理員（CMO）每個(gè)項(xiàng)目應(yīng)配備一個(gè)配置管理員（可專職或由項(xiàng)目組某個(gè)成員兼職），為該項(xiàng)目制定配置管理計(jì)劃、創(chuàng)建和維護(hù)配置庫(kù)、適時(shí)出具配置管理各種報(bào)告如基線建立控制報(bào)告、配置項(xiàng)變更控制報(bào)告、版本發(fā)布通知等。適用范圍本配置管理規(guī)范適用于公司產(chǎn)品/項(xiàng)目從可研論證、立項(xiàng)、需求分析、設(shè)計(jì)編碼、測(cè)試驗(yàn)證、版本發(fā)布、運(yùn)行維護(hù)直至結(jié)束的全生命周期過(guò)程中文檔、代碼、構(gòu)建、發(fā)布等的管理，暫不適用于其他資產(chǎn)如測(cè)試數(shù)據(jù)、美工工作產(chǎn)品、售前資料、非產(chǎn)品/項(xiàng)目培訓(xùn)資料、多媒體資料、部門管理文檔、公司信息化數(shù)據(jù)等的管理。閱讀對(duì)象配置管理員、產(chǎn)品/項(xiàng)目經(jīng)理、開(kāi)發(fā)人員、測(cè)試人員、維護(hù)人員、系統(tǒng)架構(gòu)師配置管理計(jì)劃配置管理的計(jì)劃過(guò)程主要由明確配置管理軟硬件資源、識(shí)別配置項(xiàng)、規(guī)劃配置庫(kù)目錄結(jié)構(gòu)、確定權(quán)限配置、制定基線計(jì)劃、確定項(xiàng)目分支合并策略、確定代碼集成策略、項(xiàng)目構(gòu)建策略、版本發(fā)布策略以及制定《配置管理計(jì)劃》等一系列活動(dòng)組成，每個(gè)活動(dòng)計(jì)劃的最終成果體現(xiàn)在《配置管理計(jì)劃》中。通過(guò)配置管理計(jì)劃，將項(xiàng)目開(kāi)發(fā)、測(cè)試、實(shí)施、發(fā)版各階段涉及的配置管理工作明確下來(lái)，保證項(xiàng)目生命周期過(guò)程中產(chǎn)生的配置項(xiàng)被識(shí)別、記錄、跟蹤、管理。配置管理計(jì)劃流程圖圖1配置管理計(jì)劃流程圖配置管理計(jì)劃流程說(shuō)明由項(xiàng)目經(jīng)理和配置管理員共同確定本項(xiàng)目配置管理的軟硬件資源，如下：確定CCB成員名單，根據(jù)項(xiàng)目不同規(guī)模和重要程度，CCB成員建議可以包括分管副總、研發(fā)項(xiàng)目總監(jiān)、部門經(jīng)理、項(xiàng)目經(jīng)理以及其他受變更影響的人員代表（必要時(shí)可包括測(cè)試人員等）。確定本項(xiàng)目配置管理的軟件工具和硬件設(shè)備，包括配置管理服務(wù)器、構(gòu)建服務(wù)器、軟件開(kāi)發(fā)工具、配置管理工具、構(gòu)建工具等的具體名稱和版本以及需遵循的開(kāi)發(fā)、編碼規(guī)范（確定配置管理的軟硬件資源可參考本規(guī)范以及《配置管理工作指南》相關(guān)章節(jié)內(nèi)容）。依據(jù)《項(xiàng)目管理計(jì)劃》，由配置管理員與項(xiàng)目經(jīng)理共同識(shí)別主要配置項(xiàng)、配置庫(kù)目錄及權(quán)限分配、基線計(jì)劃、分支合并策略等（具體內(nèi)容可參考本規(guī)范相關(guān)章節(jié)內(nèi)容），并體現(xiàn)在《配置管理計(jì)劃》中。配置管理員與項(xiàng)目經(jīng)理共同確定項(xiàng)目的變更策略、代碼集成策略、項(xiàng)目構(gòu)建策略以及版本發(fā)布策略（具體內(nèi)容可參考本規(guī)范相關(guān)章節(jié)內(nèi)容），并體現(xiàn)在《配置管理計(jì)劃》中。配置管理員完成《配置管理計(jì)劃》，以便于項(xiàng)目有計(jì)劃的開(kāi)展配置管理工作（配置管理計(jì)劃相關(guān)模板詳見(jiàn)公司主頁(yè)規(guī)章制度下公布的最新模板）?！杜渲霉芾碛?jì)劃》評(píng)審活動(dòng)由配置管理員發(fā)起，評(píng)審組由CCB成員組成（可同時(shí)發(fā)送項(xiàng)目組人員）。CCB對(duì)已制定的《配置管理計(jì)劃》進(jìn)行評(píng)審，以保證《配置管理計(jì)劃》的完整、正確、可行；如審批未通過(guò)，配置管理員需按照評(píng)審意見(jiàn)重新修訂《配置管理計(jì)劃》，直至CCB評(píng)審?fù)ㄟ^(guò)。配置管理員將審批通過(guò)的《配置管理計(jì)劃》納入配置庫(kù)進(jìn)行管理，并發(fā)布給項(xiàng)目組相關(guān)人員。配置管理軟硬件資源確定配置管理服務(wù)器公司所有項(xiàng)目的配置庫(kù)必須在公司指定的配置管理服務(wù)器上，包括研發(fā)項(xiàng)目和實(shí)施項(xiàng)目。公司所有項(xiàng)目使用配置管理服務(wù)器必須與運(yùn)營(yíng)監(jiān)管中心溝通確認(rèn)。公司級(jí)配置管理計(jì)劃模板中應(yīng)明確列示配置管理服務(wù)器的基本信息，如配置管理服務(wù)器名稱、操作系統(tǒng)、IP地址、內(nèi)存容量、硬盤容量、管理員等。

公司目前允許使用的配置管理服務(wù)器如下表所示：服務(wù)器名訪問(wèn)地址主要用途配置庫(kù)規(guī)劃備注jqcmr32289版全稱Subversion，研發(fā)項(xiàng)目，文檔和代碼vss\\ad01\開(kāi)發(fā)輔助\VSS版本管理6.0C/無(wú)全稱VisualSourceSafe，研發(fā)項(xiàng)目，文檔和代碼starteam\\ad01\開(kāi)發(fā)輔助\StarTeamEnterprise2008配置管理、需求管理、任務(wù)管理等2008/2006研發(fā)項(xiàng)目，文檔和代碼項(xiàng)目管理平臺(tái)Web訪問(wèn)基線建立流程圖基線計(jì)劃時(shí)間點(diǎn)到達(dá)或需要建立基線時(shí)，由項(xiàng)目經(jīng)理提出基線建立申請(qǐng)。CCB對(duì)基線建立申請(qǐng)進(jìn)行評(píng)審和批準(zhǔn)，保證組成基線的配置項(xiàng)是完整的、正確的、一致的。配置管理員與項(xiàng)目經(jīng)理溝通，參照《基線建立前檢查Checklist》以及基線計(jì)劃對(duì)提交的配置項(xiàng)審查其完整性、正確性、一致性，并完成《基線建立前檢查Checklist》、《基線建立控制報(bào)告》，填寫基線名稱、版本、標(biāo)識(shí)以及當(dāng)前基線包含的所有主要配置項(xiàng)等信息（如果前期已建立基線，當(dāng)前基線的配置項(xiàng)需要包含上一次基線的配置項(xiàng)）。配置管理員審查配置項(xiàng)時(shí)需注意檢查主要配置項(xiàng)的評(píng)審記錄、評(píng)審結(jié)論、變更影響等。比如需求規(guī)格說(shuō)明書(shū)評(píng)審記錄、功能評(píng)審記錄、變更所影響的配置項(xiàng)是否正確變更并入庫(kù)等等，如若評(píng)審結(jié)論不通過(guò)或影響的配置項(xiàng)沒(méi)有變更或入庫(kù)，則該基線不能建立并必須與項(xiàng)目經(jīng)理溝通。CCB評(píng)審并批準(zhǔn)基線建立申請(qǐng)后，由配置管理員執(zhí)行建立基線的操作，基線命名要按照《配置管理計(jì)劃》中規(guī)定的命名。配置管理員將《基線建立控制報(bào)告》發(fā)布給CCB、項(xiàng)目組成員并納入配置庫(kù)。基線命名規(guī)范計(jì)劃性基線：“項(xiàng)目編號(hào)-階段標(biāo)識(shí)-YYYYMMDD”；事件性基線：“項(xiàng)目編號(hào)-階段標(biāo)識(shí)-事件英文縮寫-YYYYMMDD”?；€名稱標(biāo)識(shí)符基線所包含的主要配置項(xiàng)建立時(shí)間產(chǎn)品定義基線項(xiàng)目編號(hào)-REQBaseline-YYYYMMDD需求說(shuō)明書(shū)需求規(guī)格說(shuō)明書(shū)項(xiàng)目管理計(jì)劃品質(zhì)保證計(jì)劃配置管理計(jì)劃測(cè)試計(jì)劃風(fēng)險(xiǎn)/重大問(wèn)題跟蹤表各種報(bào)告和跟蹤表產(chǎn)品設(shè)計(jì)與開(kāi)發(fā)基線項(xiàng)目編號(hào)-DES+CODEBaseline-YYYYMMDD概要技術(shù)方案說(shuō)明書(shū)總體設(shè)計(jì)說(shuō)明書(shū)模塊設(shè)計(jì)說(shuō)明書(shū)數(shù)據(jù)庫(kù)設(shè)計(jì)說(shuō)明書(shū)測(cè)試用例源代碼產(chǎn)品穩(wěn)定基線項(xiàng)目編號(hào)-RELEBaseline-YYYYMMDD測(cè)試報(bào)告用戶手冊(cè)培訓(xùn)資料技術(shù)白皮書(shū)發(fā)布版本產(chǎn)品結(jié)項(xiàng)基線項(xiàng)目編號(hào)-ENDBaseline-YYYYMMDD項(xiàng)目總結(jié)報(bào)告提交工作產(chǎn)品清單分支合并管理版本控制系統(tǒng)的一個(gè)特性是能夠把各種修改分離出來(lái)放在一個(gè)單獨(dú)的開(kāi)發(fā)線上，這條線被稱為分支。分支經(jīng)常被用來(lái)試驗(yàn)新的特性，而不會(huì)干擾主開(kāi)發(fā)線，當(dāng)新的特性足夠穩(wěn)定之后，開(kāi)發(fā)分支就可合并到主干里。分支管理是軟件版本控制的重要組成部分，運(yùn)用分支使得并行開(kāi)發(fā)的系統(tǒng)、同步更改多個(gè)并行版本的錯(cuò)誤等成為可能。分支可用來(lái)維護(hù)獨(dú)立的開(kāi)發(fā)支線（通常只對(duì)代碼做分支），使用分支進(jìn)行項(xiàng)目組的開(kāi)發(fā)可以提高項(xiàng)目組的開(kāi)發(fā)速度，并減少對(duì)主干文件的誤修改操作，否則主干版本可能會(huì)變得十分混亂，維護(hù)難度大大加大。盡管SVN沒(méi)有做強(qiáng)制要求，但SVN版本目錄建議創(chuàng)建Trunk、Branches、Tags三個(gè)目錄。其中Branches是分支目錄，存放并行開(kāi)發(fā)的項(xiàng)目文檔和代碼；Tags是標(biāo)簽?zāi)夸?，存放所定義基線的項(xiàng)目文檔和代碼。分支建立分支建立時(shí)機(jī)建立分支是為了支持特定需求、完成新功能開(kāi)發(fā)或解決某些重大bug，在項(xiàng)目立項(xiàng)、新增功能需求、解決某些重大bug等情況下允許建立分支。由配置管理員協(xié)助開(kāi)發(fā)人員在配置庫(kù)相應(yīng)目錄下建立分支。應(yīng)當(dāng)盡量避免建立多個(gè)層次的分支，即基于分支再創(chuàng)建分支。分支建立模式一般情況下，圍繞代碼進(jìn)行分支管理的模式主要有兩種：主干作為新功能開(kāi)發(fā)，分支用作穩(wěn)定版的發(fā)布；分支用作新功能開(kāi)發(fā)，主干作為穩(wěn)定版的發(fā)布。建立分支時(shí)，配置管理員需明確以下幾點(diǎn)：分支目錄結(jié)構(gòu)；人員訪問(wèn)權(quán)限；此分支是否需提交相關(guān)項(xiàng)目文檔。分支合并分支合并類型分支合并是將某個(gè)分支中修改的代碼合并到另一個(gè)分支中。常見(jiàn)的分支合并有以下幾種：分支合并到分支；分支合并到主干；主干合并到分支。分支合并前應(yīng)臨時(shí)去除相關(guān)分支所有人員的寫權(quán)限，只保留被合并分支上合并人員的寫權(quán)限。應(yīng)當(dāng)盡量避免一個(gè)分支合并多次。當(dāng)一個(gè)分支完成特定任務(wù)后，應(yīng)及時(shí)合并。合并完成后分支應(yīng)設(shè)置為只讀，不再允許對(duì)該分支進(jìn)行修改。版本庫(kù)發(fā)布模式新功能開(kāi)發(fā)在主干上進(jìn)行當(dāng)新功能開(kāi)發(fā)在主干上進(jìn)行、臨近發(fā)布階段時(shí)，從主干建立分支，在分支上修訂集成測(cè)試、系統(tǒng)測(cè)試所發(fā)現(xiàn)的BUG，在分支上進(jìn)行發(fā)版；主干繼續(xù)進(jìn)行新功能開(kāi)發(fā)。版本發(fā)布完成后，將分支合并到主干，分支設(shè)置為只讀。新功能開(kāi)發(fā)在分支上進(jìn)行當(dāng)新功能開(kāi)發(fā)在分支上進(jìn)行、開(kāi)發(fā)結(jié)束、功能測(cè)試通過(guò)時(shí)，將分支合并到主干修訂集成測(cè)試、系統(tǒng)測(cè)試所發(fā)現(xiàn)的BUG，在主干上進(jìn)行發(fā)版；同時(shí)將分支設(shè)置為只讀。此模式下的開(kāi)發(fā)周期較靈活，各功能模塊自主定義開(kāi)發(fā)周期，分支上的開(kāi)發(fā)臨近末期則將分支合并至主干，越先合并的分支，在合并過(guò)程中解決的沖突越小。代碼集成管理代碼集成目標(biāo)是使集成和集成測(cè)試過(guò)程處于受控狀態(tài)。頻繁的集成能夠幫助項(xiàng)目在早期發(fā)現(xiàn)項(xiàng)目風(fēng)險(xiǎn)和質(zhì)量問(wèn)題，如果到后期才發(fā)現(xiàn)這些問(wèn)題，解決問(wèn)題的代價(jià)將會(huì)很大、并且很有可能導(dǎo)致項(xiàng)目延期或者失敗。當(dāng)產(chǎn)品/項(xiàng)目進(jìn)入編碼階段后，不同開(kāi)發(fā)人員在各自的個(gè)人工作空間下開(kāi)始編碼。為保證代碼集成目標(biāo)的實(shí)現(xiàn)、避免不同開(kāi)發(fā)人員提交到代碼庫(kù)的代碼產(chǎn)生沖突，必須明確約定從個(gè)人工作空間到代碼庫(kù)的代碼集成策略：禁止使用有商業(yè)版權(quán)、未經(jīng)授權(quán)的工具、軟件或插件。同一個(gè)產(chǎn)品或項(xiàng)目的開(kāi)發(fā)應(yīng)統(tǒng)一個(gè)人工作空間，一般包括以下內(nèi)容：操作系統(tǒng)、配置管理工具客戶端或插件版本、開(kāi)發(fā)工具及版本、數(shù)據(jù)庫(kù)及版本、中間件及版本以及其他環(huán)境要求等。個(gè)人工作空間要求應(yīng)由項(xiàng)目經(jīng)理與配置管理員共同確定并體現(xiàn)在項(xiàng)目管理計(jì)劃和配置管理計(jì)劃中。個(gè)人工作空間目錄應(yīng)該盡可能的與服務(wù)器目錄結(jié)構(gòu)保持一致，禁止自行將多個(gè)文檔目錄或工程代碼合并到一個(gè)目錄或工程之中進(jìn)行工作。工作時(shí)如需鎖定或Checkout文件，在修改完成后應(yīng)該馬上解鎖文件，禁止長(zhǎng)期鎖定或當(dāng)產(chǎn)品/項(xiàng)目處于前期開(kāi)發(fā)階段時(shí)，開(kāi)發(fā)人員根據(jù)項(xiàng)目組要求應(yīng)該每天至少向配置庫(kù)中提交一次代碼、每天至少?gòu)呐渲脦?kù)更新一次相關(guān)的代碼到個(gè)人工作空間。開(kāi)發(fā)人員向配置庫(kù)提交代碼前必須先在個(gè)人工作空間完成編譯、構(gòu)建、自測(cè)，保證代碼可編譯通過(guò)、沒(méi)有錯(cuò)誤，從而確保配置庫(kù)的變更不會(huì)導(dǎo)致代碼集成失敗。當(dāng)產(chǎn)品/項(xiàng)目處于后期版本穩(wěn)定階段時(shí)，對(duì)于產(chǎn)品版本穩(wěn)定性要求較大的開(kāi)發(fā)團(tuán)隊(duì)，為避免由于代碼集成過(guò)程缺乏控制導(dǎo)致的代碼混亂問(wèn)題，必須制定嚴(yán)密的代碼集成策略。跟產(chǎn)品/項(xiàng)目無(wú)關(guān)的文件一律不允許檢入配置庫(kù)，如編譯產(chǎn)生的文件、緩存縮略圖的文件Thumbs.db、從VSS中檢出的配置文件vssver.scc等。源代碼必須及時(shí)提交到配置庫(kù)，不允許長(zhǎng)時(shí)間lock或checkout代碼而不執(zhí)行unlock或checkin。lock或checkout到unlock或checkin的時(shí)間間隔不得超過(guò)2個(gè)星期。對(duì)于開(kāi)發(fā)人員，修復(fù)失敗的構(gòu)建是優(yōu)先級(jí)最高的事情。代碼修改過(guò)程中，為防止代碼被別人修改而引發(fā)沖突，可以考慮鎖定機(jī)制。正式版本發(fā)布、升級(jí)或發(fā)布臨時(shí)版本時(shí)，必須對(duì)源代碼打基線。配置管理員與項(xiàng)目經(jīng)理溝通確定代碼集成策略后，將具體的流程在《配置管理計(jì)劃》中做出約定，主要內(nèi)容如下：代碼集成策略內(nèi)容包括：代碼模塊集成順序、誰(shuí)負(fù)責(zé)代碼集成過(guò)程、代碼集成前的一致性檢查、代碼提交要求等，參見(jiàn)《配置管理工作指南》代碼集成部分的內(nèi)容代碼集成策略影響整個(gè)系統(tǒng)各個(gè)代碼模塊的編譯順序和目標(biāo)代碼的連接（受一些構(gòu)建參數(shù)的影響），項(xiàng)目經(jīng)理要根據(jù)代碼集成策略確定構(gòu)建腳本和相關(guān)構(gòu)建參數(shù)，確保構(gòu)建腳本及其配置參數(shù)符合代碼集成策略要求，配置管理員要注意督促。源代碼基線建立或第一次版本發(fā)布后，所有源代碼的修改、提交必須填寫修改注釋（COMMENTS）或更新說(shuō)明。產(chǎn)品/項(xiàng)目穩(wěn)定后期，可設(shè)立專門的代碼集成人員，開(kāi)發(fā)人員將修改文件及更新說(shuō)明（明確注明修改文件、修改原因等信息）發(fā)送給代碼集成人員，由代碼集成人員向代碼庫(kù)提交代碼，并維護(hù)代碼庫(kù)更新說(shuō)明列表。發(fā)布管理正式版本發(fā)布正式版本是指經(jīng)測(cè)試后、可發(fā)布給客戶正式使用的版本，包括程序包、更新腳本、用戶文檔等。對(duì)外發(fā)布的正式版本包中不得包含任何未經(jīng)授權(quán)的產(chǎn)品或半產(chǎn)品，比如不得使用未經(jīng)授權(quán)的商業(yè)軟件工具構(gòu)建程序包、創(chuàng)建文檔、制作圖片等，不得使用第三方獲取的未經(jīng)授權(quán)的圖片等。各產(chǎn)品/項(xiàng)目正式發(fā)布的版本包必須存放在久其產(chǎn)品庫(kù)中。久其產(chǎn)品庫(kù)按照產(chǎn)品線/項(xiàng)目進(jìn)行目錄規(guī)劃。久其產(chǎn)品庫(kù)由組織級(jí)配置管理員在對(duì)應(yīng)的目錄上針對(duì)產(chǎn)品線或項(xiàng)目配置管理員開(kāi)放讀寫權(quán)限，針對(duì)測(cè)試、實(shí)施、服務(wù)相關(guān)部門經(jīng)理/負(fù)責(zé)人、助理開(kāi)放讀權(quán)限。如需訪問(wèn)久其產(chǎn)品庫(kù)某產(chǎn)品，需經(jīng)主管領(lǐng)導(dǎo)、分管副總審批后由組織級(jí)配置管理員設(shè)定；沒(méi)有經(jīng)過(guò)申請(qǐng)、審批的人員不設(shè)置任何權(quán)限。正式產(chǎn)品的發(fā)布必須提交發(fā)版說(shuō)明或者更新說(shuō)明。正式版本的命名一般遵循“產(chǎn)品/項(xiàng)目編號(hào)+正式版本號(hào)+內(nèi)部版本號(hào)+八位數(shù)日期+隨機(jī)號(hào)”。正式版本的發(fā)布由配置管理員采用電子郵件方式統(tǒng)一執(zhí)行，發(fā)送范圍視版本內(nèi)容可以是全公司或部分人員。久其產(chǎn)品庫(kù)要做到每年做一次完全備份，并且刻盤、永久歸檔。測(cè)試版本發(fā)布測(cè)試版本是指構(gòu)建完成后僅用于內(nèi)部測(cè)試驗(yàn)證、臨時(shí)滿足用戶演示或售前交流等需要臨時(shí)發(fā)布的版本，是非正式的產(chǎn)品版本，使用對(duì)象包括內(nèi)部測(cè)試人員或外部客戶（協(xié)助測(cè)試）。測(cè)試版本不能保證產(chǎn)品整體功能的正確性，是未經(jīng)過(guò)功能測(cè)試、集成測(cè)試或性能測(cè)試的版本，不得用于正式生產(chǎn)環(huán)境。各產(chǎn)品/項(xiàng)目構(gòu)建工作建議在久其統(tǒng)一的構(gòu)建服務(wù)器、通用構(gòu)建管理平臺(tái)上執(zhí)行。各產(chǎn)品/項(xiàng)目必須有一個(gè)唯一的標(biāo)識(shí)，用于區(qū)分不同產(chǎn)品/項(xiàng)目的構(gòu)建。測(cè)試版本的構(gòu)建必須由配置管理員或指定的構(gòu)建人員執(zhí)行。構(gòu)建產(chǎn)生的測(cè)試版本存放在構(gòu)建服務(wù)器上，有相應(yīng)授權(quán)的人員可以登錄構(gòu)建平臺(tái)下載。測(cè)試版本的命名一般遵循“yyyy-mm-dd（hh-mm-ss）”的規(guī)則。一般情況下，測(cè)試版本保存半年之后可以刪除、無(wú)須永久備份。臨時(shí)版本發(fā)布臨時(shí)版本是指為了滿足用戶少量個(gè)性化需求或修復(fù)部分小缺陷而發(fā)布的版本，這種版本一般可以不經(jīng)過(guò)集成測(cè)試，但應(yīng)經(jīng)功能測(cè)試方可發(fā)布。為了做好版本管理、一般情況下應(yīng)盡可能減少臨時(shí)版本的發(fā)布。臨時(shí)發(fā)布的版本包中同樣不得包含任何未經(jīng)授權(quán)的產(chǎn)品或半產(chǎn)品。因臨時(shí)版本需要用于正式生產(chǎn)環(huán)境，所以臨時(shí)版本同樣必須存放在久其產(chǎn)品庫(kù)中。臨時(shí)版本存儲(chǔ)的目錄結(jié)構(gòu)劃分、權(quán)限設(shè)置等與產(chǎn)品/項(xiàng)目的正式版本一致。臨時(shí)版本的命名一般遵循“產(chǎn)品/項(xiàng)目編號(hào)+正式版本號(hào)+內(nèi)部版本號(hào)+八位數(shù)日期+隨機(jī)號(hào)+用戶方或者申請(qǐng)者姓名”。臨時(shí)版本可視情況考慮永久歸檔或者在保存一年之后刪除。變更管理變更控制為了確保重大變更經(jīng)過(guò)評(píng)審、確認(rèn)，保證變更所引起的其他配置項(xiàng)能夠得到及時(shí)、一致的更新并及時(shí)入庫(kù)，保證所有事件性變更有記錄，我們需要加強(qiáng)變更控制。對(duì)于嚴(yán)重影響項(xiàng)目進(jìn)度和成本的需求、設(shè)計(jì)、人員、計(jì)劃等的變更必須經(jīng)過(guò)申請(qǐng)、評(píng)審、審批方可執(zhí)行，不允許擅自修改。修改處于“草稿”狀態(tài)的配置項(xiàng)不算是“變更”，當(dāng)配置項(xiàng)的狀態(tài)成為“正式發(fā)布”，或者被“凍結(jié)”后，此時(shí)任何人都不能隨意修改，必須依據(jù)申請(qǐng)執(zhí)行變更的規(guī)則執(zhí)行。發(fā)生變更時(shí)，項(xiàng)目經(jīng)理必須及時(shí)通知配置管理員，延緩時(shí)間不能超過(guò)3天。配置管理員要跟蹤變更執(zhí)行進(jìn)度，及時(shí)接收、入庫(kù)變更產(chǎn)生或修改的配置項(xiàng)。對(duì)配置項(xiàng)的變更操作應(yīng)以評(píng)審定稿為準(zhǔn)、不僅僅以基線為準(zhǔn)。即：配置項(xiàng)評(píng)審定稿入庫(kù)后、未建立基線前如對(duì)該配置項(xiàng)進(jìn)行修改，需按照變更流程執(zhí)行。配置管理通過(guò)建立一個(gè)有序的變更控制過(guò)程要確保以下幾點(diǎn)：變更影響分析：對(duì)每個(gè)配置項(xiàng)的變更所造成的影響（如：技術(shù)影響、成本影響、進(jìn)度影響等）需進(jìn)行分析。變更審批：對(duì)任何基線化的配置項(xiàng)的更改必須經(jīng)過(guò)審批、并保留審批記錄。變更執(zhí)行與入庫(kù)：得到審批的變更及其影響必須得以實(shí)施并得到進(jìn)一步審批方可入庫(kù)。變更流程圖1變更控制流程圖申請(qǐng)變更變更申請(qǐng)人向CCB提交變更申請(qǐng)（填寫《配置項(xiàng)變更控制報(bào)告》的相關(guān)內(nèi)容），需要重點(diǎn)說(shuō)明“變更內(nèi)容”和“變更原因”及其“該配置項(xiàng)變更對(duì)項(xiàng)目造成的影響”。典型的變更請(qǐng)求有：項(xiàng)目目標(biāo)發(fā)生改變、增加或減少重大功能需求、技術(shù)攻關(guān)出現(xiàn)難題、資源調(diào)整等。評(píng)審變更申請(qǐng)CCB評(píng)審該申請(qǐng)，重點(diǎn)分析此變更對(duì)項(xiàng)目造成的影響。安排變更