軟件開發(fā)三庫管理流程規(guī)范文檔一、目的與范圍（一）目的為規(guī)范軟件開發(fā)過程中開發(fā)庫、受控庫、產(chǎn)品庫（簡稱“三庫”）的管理，確保軟件配置項（代碼、文檔、配置文件等）的完整性、可追溯性與版本一致性，支撐開發(fā)、測試、交付等環(huán)節(jié)有序開展，降低協(xié)作風(fēng)險，提升軟件產(chǎn)品質(zhì)量，特制定本流程規(guī)范。（二）適用范圍本規(guī)范適用于公司所有軟件開發(fā)項目（含自研、外包協(xié)作項目）的三庫管理，覆蓋從需求分析到產(chǎn)品交付、運維的全生命周期配置項管理。涉及角色包括開發(fā)人員、測試人員、配置管理員、項目經(jīng)理、質(zhì)量管理人員及客戶方相關(guān)人員。二、三庫定義與核心特性（一）開發(fā)庫（動態(tài)庫/工作庫）開發(fā)人員日常開發(fā)的“工作區(qū)”，存放未經(jīng)過正式評審、處于迭代狀態(tài)的軟件配置項（如代碼草稿、臨時文檔、測試用例初稿等）。動態(tài)性：隨開發(fā)過程持續(xù)更新，無嚴格版本凍結(jié)要求；自主性：開發(fā)人員可自主提交、修改、刪除內(nèi)容（需保留操作記錄）；非受控性：內(nèi)容暫不具備“基線”屬性，僅服務(wù)于個人/小組開發(fā)協(xié)作。（二）受控庫（基線庫/主庫）存放經(jīng)過評審、正式納入“基線”管理的軟件配置項，是開發(fā)過程中“里程碑”級成果的集合（如需求基線、設(shè)計基線、代碼基線等）。受控性：內(nèi)容變更需遵循“申請-評審-批準(zhǔn)-執(zhí)行”的嚴格流程；基線化：每個版本對應(yīng)明確的開發(fā)階段（如“V1.0需求基線”“V2.1代碼基線”），作為后續(xù)開發(fā)、測試的基準(zhǔn)；追溯性：所有變更需記錄原因、執(zhí)行人、時間，支持問題回溯。（三）產(chǎn)品庫（靜態(tài)庫/發(fā)布庫）存放最終通過驗收、面向客戶交付或部署的軟件產(chǎn)品版本，是軟件生命周期的“終態(tài)”成果。靜態(tài)性：版本一旦入庫，原則上不允許修改（緊急缺陷修復(fù)需走特殊流程）；交付性：直接用于生產(chǎn)環(huán)境部署、客戶交付或歸檔；權(quán)威性：版本號與交付文檔一一對應(yīng)，是項目驗收、運維的唯一依據(jù)。三、三庫管理核心流程（一）入庫管理1.開發(fā)庫入庫開發(fā)人員完成單日/階段開發(fā)后，將代碼、文檔等成果提交至開發(fā)庫對應(yīng)目錄（如按模塊、功能劃分的子庫）。提交時需填寫《開發(fā)庫入庫單》（含版本說明、修改內(nèi)容摘要、關(guān)聯(lián)任務(wù)編號等），便于團隊追溯。支持“增量提交”（僅提交修改部分）與“全量提交”（首次提交或重大重構(gòu)時），建議通過Git、SVN等版本控制系統(tǒng)實現(xiàn)。2.受控庫入庫前提：配置項需通過正式評審（如需求評審、代碼評審、測試評審）且結(jié)論為“通過”。配置管理員將開發(fā)庫中通過評審的配置項（含代碼、文檔、測試報告等）遷移至受控庫，生成基線版本（如“V1.0.0_需求基線”）。入庫時需填寫《受控庫基線入庫單》，記錄基線名稱、版本號、入庫時間、關(guān)聯(lián)評審報告編號等，同步更新《配置項狀態(tài)跟蹤表》。3.產(chǎn)品庫入庫前提：受控庫中的基線版本通過用戶驗收測試（UAT）或客戶確認，滿足交付標(biāo)準(zhǔn)。配置管理員將受控庫中通過驗收的基線版本遷移至產(chǎn)品庫，生成發(fā)布版本（如“V1.0.0_RELEASE”）。入庫時需填寫《產(chǎn)品庫發(fā)布入庫單》，記錄版本號、交付日期、客戶名稱（或部署環(huán)境）等，同步輸出《產(chǎn)品交付清單》。（二）出庫管理1.開發(fā)庫出庫開發(fā)人員可通過版本控制系統(tǒng)（如Gitpull、SVNupdate）從開發(fā)庫獲取最新代碼/文檔，用于本地開發(fā)。出庫無需審批，但需記錄操作（由版本控制系統(tǒng)自動生成日志），確保團隊代碼同步。2.受控庫出庫開發(fā)需求：開發(fā)人員因功能迭代、缺陷修復(fù)需修改受控庫基線時，需提交《受控庫出庫申請單》，說明出庫原因（關(guān)聯(lián)需求/缺陷編號）、修改范圍、預(yù)計回歸測試內(nèi)容。測試/評審需求：測試人員、評審專家因驗證、評審需獲取受控庫基線時，需提交申請，說明用途（如“V2.1.0代碼基線測試驗證”）。申請經(jīng)項目經(jīng)理/技術(shù)負責(zé)人審批通過后，配置管理員協(xié)助出庫（或授權(quán)申請人通過指定工具獲?。⒂涗洝俺鰩鞎r間、申請人、用途、預(yù)計歸還時間”。3.產(chǎn)品庫出庫僅用于生產(chǎn)環(huán)境部署或客戶交付，需提交《產(chǎn)品庫出庫申請單》，說明出庫版本、部署環(huán)境（或客戶名稱）。申請經(jīng)項目經(jīng)理+客戶方代表（或運維負責(zé)人）審批通過后，配置管理員將產(chǎn)品包（含安裝手冊、版本說明）交付至指定人員/環(huán)境，記錄出庫時間、接收人、交付方式。（三）變更管理1.變更觸發(fā)條件需求變更：客戶新增/修改需求，或內(nèi)部需求迭代；缺陷修復(fù)：測試/生產(chǎn)環(huán)境發(fā)現(xiàn)的Bug需修復(fù)；優(yōu)化升級：性能優(yōu)化、架構(gòu)調(diào)整等非功能性需求。2.變更流程（以受控庫為例）1.變更申請：申請人提交《配置項變更申請表》，說明變更原因、影響范圍、涉及的配置項、預(yù)計變更時長。2.變更評審：項目經(jīng)理組織開發(fā)、測試、質(zhì)量人員評審，評估變更必要性、風(fēng)險（如對現(xiàn)有功能的影響、回歸測試范圍），結(jié)論為“通過”“有條件通過”或“駁回”。3.變更執(zhí)行：評審?fù)ㄟ^后，申請人從受控庫出庫（或從開發(fā)庫獲取基線版本），在開發(fā)庫完成修改；修改后需通過單元測試、集成測試（代碼類）或文檔評審（文檔類）。4.變更驗證：測試人員對變更內(nèi)容進行回歸測試（或評審），確認變更解決問題且未引入新缺陷。5.變更入庫：配置管理員將驗證通過的配置項重新提交至受控庫，更新基線版本（如V2.1.0→V2.1.1），同步更新《配置項狀態(tài)跟蹤表》與版本日志。6.變更通知：配置管理員向相關(guān)方同步變更內(nèi)容與版本更新，確保信息一致。3.特殊說明：開發(fā)庫與產(chǎn)品庫變更開發(fā)庫：開發(fā)人員可自主變更（如代碼調(diào)試、臨時文檔修改），但需保留操作記錄（如Git提交日志）；“重大變更”（如模塊重構(gòu)）需同步告知團隊。產(chǎn)品庫：原則上禁止變更。若生產(chǎn)環(huán)境出現(xiàn)緊急缺陷，需啟動“緊急變更流程”：由項目經(jīng)理+技術(shù)負責(zé)人+客戶方（或運維）審批，修改后需通過嚴格測試，重新生成產(chǎn)品版本并入庫（版本號標(biāo)記為“V1.0.1_HOTFIX”），同步更新交付文檔。（四）版本管理1.版本命名規(guī)則開發(fā)庫：內(nèi)部迭代版，格式為`V<主版本>.<次版本>.<修訂版本>.dev<迭代次數(shù)>`（如V0.1.2.dev3）；受控庫：基線版，格式為`V<主版本>.<次版本>.<修訂版本>`（如V1.0.0）；產(chǎn)品庫：發(fā)布版，格式為`V<主版本>.<次版本>.<修訂版本>.RELEASE`（如V1.0.0.RELEASE）。2.版本升級規(guī)則主版本（X）：需求重大變更（如架構(gòu)重構(gòu)），需重新評審需求基線；次版本（Y）：新增功能模塊或?qū)ΜF(xiàn)有功能進行較大優(yōu)化，需通過功能評審；修訂版本（Z）：僅修復(fù)缺陷或進行微小優(yōu)化，無需變更需求基線，通過缺陷修復(fù)評審即可。3.版本追溯與回滾所有版本需在《版本管理臺賬》中記錄（含版本號、創(chuàng)建時間、變更內(nèi)容、責(zé)任人）；若變更引入新問題，可通過版本控制系統(tǒng)回滾至歷史版本（需經(jīng)項目經(jīng)理審批），回滾后需重新驗證并更新版本日志。（五）權(quán)限管理1.角色與權(quán)限矩陣角色開發(fā)庫權(quán)限受控庫權(quán)限產(chǎn)品庫權(quán)限--------------------------------------------------開發(fā)人員讀寫/刪除只讀（變更需申請）只讀測試人員只讀（調(diào)試時可寫）讀寫（測試驗證時）只讀配置管理員讀寫/刪除讀寫/刪除（管理）讀寫/刪除（管理）項目經(jīng)理只讀審批/只讀審批/只讀客戶方代表只讀只讀（評審時）讀寫（驗收時）2.權(quán)限申請與變更新員工入職或角色變更時，需提交《權(quán)限申請表》，經(jīng)直屬領(lǐng)導(dǎo)+配置管理員審批后開通權(quán)限；權(quán)限變更（如臨時提升測試人員的受控庫寫權(quán)限）需提交申請，說明原因與有效期，經(jīng)項目經(jīng)理審批后執(zhí)行。（六）審計與追溯1.日常審計配置管理員每周對三庫進行“配置項一致性審計”：檢查開發(fā)庫與受控庫的基線版本是否同步、受控庫與產(chǎn)品庫的版本是否匹配；每月輸出《三庫審計報告》，記錄問題清單（如“開發(fā)庫存在未提交的代碼變更”）及整改措施。2.問題追溯當(dāng)出現(xiàn)缺陷、需求偏差等問題時，可通過《版本管理臺賬》+操作日志追溯變更歷史：確認變更執(zhí)行人、時間、原因，定位問題根源；重大問題需啟動“根因分析（RCA）”，結(jié)合三庫記錄還原事件過程，輸出改進措施。四、職責(zé)分工（一）配置管理員負責(zé)三庫日常維護（目錄結(jié)構(gòu)設(shè)計、權(quán)限配置、備份恢復(fù)）；執(zhí)行入庫、出庫、版本更新操作，維護《配置項狀態(tài)跟蹤表》《版本管理臺賬》；組織/參與三庫審計，輸出審計報告，推動問題整改；協(xié)助開發(fā)、測試人員解決三庫操作中的技術(shù)問題（如版本沖突、權(quán)限報錯）。（二）開發(fā)人員遵循三庫管理流程，規(guī)范提交代碼、文檔至開發(fā)庫，確保內(nèi)容完整、注釋清晰；提交變更申請時，如實填寫變更原因、影響范圍，配合測試、評審工作；參與三庫審計，對“開發(fā)庫不規(guī)范提交”問題進行整改。（三）測試人員基于受控庫基線開展測試工作，確保測試版本與開發(fā)提交版本一致；驗證變更內(nèi)容的有效性，提交測試報告，明確“通過/不通過”結(jié)論；參與變更評審，從測試角度評估變更風(fēng)險（如回歸測試范圍、測試用例更新需求）。（四）項目經(jīng)理審批出庫、變更、權(quán)限申請，平衡進度與質(zhì)量風(fēng)險；組織需求、代碼、交付評審，確認基線入庫的必要性；監(jiān)督三庫管理流程執(zhí)行，協(xié)調(diào)跨部門協(xié)作問題（如客戶需求變更、資源沖突）。（五）質(zhì)量管理人員監(jiān)督三庫管理流程的合規(guī)性，對審計發(fā)現(xiàn)的流程漏洞提出優(yōu)化建議；參與重大變更評審，從質(zhì)量體系角度評估變更對產(chǎn)品質(zhì)量的影響；推動三庫管理的持續(xù)改進（如引入自動化工具、優(yōu)化流程文檔）。五、注意事項與應(yīng)急處理（一）日常注意事項1.備份與恢復(fù)配置管理員需每日對開發(fā)庫、受控庫進行增量備份，每周進行全量備份，備份文件需存儲至異地服務(wù)器；產(chǎn)品庫需每次版本更新后進行全量備份，備份文件需加密存儲，確保交付版本可追溯。2.沖突解決開發(fā)庫代碼沖突：由沖突雙方協(xié)商解決，參考“最新提交優(yōu)先”或“功能重要性”原則，解決后需重新提交并備注沖突解決過程；受控庫基線沖突：禁止直接修改，需提交變更申請，由配置管理員協(xié)調(diào)相關(guān)人員評審后處理。3.文檔一致性代碼、文檔、測試用例需保持版本同步：開發(fā)庫中，代碼提交需同步更新相關(guān)文檔（如接口文檔、設(shè)計文檔）；受控庫中，基線版本需包含“代碼+文檔+測試用例”的完整集合。（二）應(yīng)急處理1.庫損壞/數(shù)據(jù)丟失立即啟動“備份恢復(fù)流程”：配置管理員從異地備份服務(wù)器恢復(fù)最新備份文件，驗證數(shù)據(jù)完整性（如代碼編譯、文檔打開測試）；若備份文件失效，組織開發(fā)、測試人員從本地工作區(qū)恢復(fù)最新版本，重新提交至開發(fā)庫，補充入庫記錄。2.權(quán)限泄露/誤操作發(fā)現(xiàn)權(quán)限泄露時，配置管理員立即凍結(jié)相關(guān)賬號，重新審計權(quán)限配置，更新《權(quán)限管理臺賬》；誤操作（如誤刪除代碼、誤提交錯誤版本）發(fā)生后，立即通過版本控制系統(tǒng)回滾至歷史版本，評估影響范圍，同步告知相關(guān)方并記錄整改措施。六、附則（一）文檔生效與修訂本規(guī)范自2024年X月X日起生效，由技術(shù)管理部負責(zé)解釋與修訂；修訂需經(jīng)項目經(jīng)理+質(zhì)量管理人員評審?fù)ㄟ^，修訂記錄需同步至《文檔修訂臺賬》。（二）術(shù)語解釋配置項（CI）：軟件生命周期中產(chǎn)生的所有可管理的內(nèi)容（如代碼、文檔、測試用例等）；基線（Baseline）：一