自己動手，開發基於工作流的全生命週期配置管理系統

做了6年的配置管理，一直在用自己公司開發的配置管理系統。但是基於cvs的特性，總有一些不如意的地方。於是就想，能不能重新開發一套開源的基於工作流的與svn緊密結合的配置管理系統。

在我的設想中，理想的配置管理系統，應該包含以下功能模組，以便做到涵蓋軟體的整個生命週期。

需求管理：需求管理中，按以下流程工作：

使用者提出需求---->ccb確認需求---->需求分析人員分析需求---->評審需求--發布需求基線---->......---->需求發布（到使用者）。

在這中間，ccb可以拒絕需求。或將使用者提出的需求確認為新需求或與已經發布的需求關聯，生成變更需求。需求分析人員，分析需求，根據需要可以擴充套件成跨產品的復合需求，並生成復合需求單。並分析需求，生成需求分析文件，提交評審，評審問題解決後，由cm發布需求基線。

設計管理：設計管理中,流程如下：需求文件---->功能點（設計文件）---->評審---->設計完成（到編碼階段）

評審管理：評審流程按專案階段分為：需求評審、設計評審、**評審（走查），按形式分為：會議評審、離線評審。會議評審需要預定會議室等，需要會議記錄員，需要投影儀等裝置。離線評審則可以通過系統，讓相關人簽收即可。

評審流程如下：評審計畫提出---->問題提出---->問題修正---->評審通過（基線發布）。

需求任務：原始需求---->分析後需求單---->任務單完成。

設計任務：分析後需求單---->設計後產物（功能點）---->任務單完成。

開發任務：功能點---->**編寫---->編譯（通過進入測試狀態，不通過進入開發狀態）---->測試（通過，任務完成、未通過提出bug）---->任務單完成。

由於這是乙個基於工作流的系統，所以任務單的狀態變更，也會導致需求單、設計單的狀態變化，乙個需求或設計任務可能會有多個任務單,所以需求單或設計單的狀態需要綜合考慮。

介面管理：介面分為資料庫介面、**介面及配置檔案介面。按申請型別分為：新增和變更。提交介面變更，提交變更必須選任務單或bug。

流程如下：提出申請---->審批申請---->變更申請---->發布變更。

資料庫管理：資料庫變更，不只是增減字段，還包括字段型別、長度、索引建立刪除、優化執行計畫、儲存過程、觸發器等。提交變更必須選任務單或bug單。

流程如下：提出申請---->審批申請---->變更申請---->發布變更。

原始碼管理：包括**變更、編譯、打tag、環境準備、分支管理、合併等。

流程如下：提交編譯---->編譯（通過打tag，獲取編譯結果特徵串，比如hash值，不通過轉開發）---->冒煙測試（通過轉qa測試、不通過轉開發）---->qa測試---->發布。

bug管理：提交bug需要關聯任務單或由工程故障生成。

qa提出bug---->dev處理bug---->qa關閉bug（不通過轉dev再處理）。

發布管理：發布管理包括，版本管理、標籤管理、發布管理。按型別分為：需求基線發布、設計基線發布、發布基線發布。

發布資訊包括：文件、模板、資料庫變更、配置檔案、需求、bug、資料庫變更、介面變更等。

發布提出---->發布資訊收集---->功能審計---->物理審計---->發布---->發布反饋

工程故障管理：提交工程故障，需要選需求。

工程故障---->qa_ld分派任務---->qa診斷**需求或bug或關閉）---->工程故障關閉。

報表管理：用於統計、展示各種流程資訊、比如月完成需求數、完成任務單數、新增bug數等。

計畫管理：用於跟蹤從需求到發布的所有過程。分發布計畫、開發計畫、測試計畫等，可以設定需求的緊急程度，故障的嚴重程度。跟蹤、修改需求、任務單、bug的最後完成時間等。

系統管理：基礎資料維護，各種列舉值、產品、工程、模組資訊等。

使用者管理：包括許可權管理、角色管理、使用者管理、離職工作移交等

在整個系統中，不只是**存放在svn中，在各種變更中用到的文件也需要存放在svn中。

盡量做到無須單獨的文件管理，全部通過系統存放在svn中。

要求與svnmanager、viewvc整合，實現視覺化管理svn。

要求對svn命令封裝，實現多分枝、多工並行、序列開發。可以在指令碼中執行原始碼管理中的操作。

在提交編譯單中與任務或bug關聯。自動獲取變更檔案提交後的版本，記入資料庫，以便跟蹤。

要求做到在發布後，通過被發布檔案，查詢出相關聯的需求、設計、評審、故障、介面、任務單、編譯單、原始碼等，以便做故障修復、回退等操作。

要求這個系統實現單點登入，以便與域伺服器、郵件伺服器等整合。

最好在最後與工時、報銷、請假等系統結合在一起，成為軟體公司的核心系統。