配置管理是個「小怪獸」
那麼按照這個邏輯，軟體研發的管理，也應該越來越厲害才對啊~然鵝……很多初級的軟體專案管理問題，仍然困擾著我們。細想想，為啥大家嘴上一直說「管理很重要」，行動上卻又不願意為此投入呢一張圖告訴你!
我一直在想，在專案管理的眾多領域裡，到底哪乙個，可以快速反應出管理改進的好處呢專案經理幫我找到了答案。
這挺讓我欣喜的，這正好論證了我們建立的pm核心能力架構的雙支柱——過程能力和領導能力。
軟體的需求哪有不變的，為啥需求變更讓人如此「害怕」呢控制變更的「變更過程」從概念上講是比較簡單的，但執行起來卻複雜的很——因為需求變更驅動設計變更，設計變更影響**，後面，測試可能發現進一步變更的問題，導致原始需求的變更……即使小規模的專案，參與變更的人員和工作量都大的驚人，如果不進行有效的管控，將引發不計其數的各種問題。
既然變是恆常，除了佛系一點，還能咋辦
變更是引入配置管理最為重要的原因。不能停止變更，就只能管好變更。變更的發生通常很「任性」，這就基本上明確了配置管理的跨度，將伴隨整個軟體生命週期。
由於配置管理，覆蓋到了整個軟體生命週期的全部重要產出，因此，它還能解決很多其他常見問題，比如：
-需求、設計、編碼、測試等工作產品的不一致性
-無法找到軟體的前一版本
-產品公升級和維護的時候，找不到軟體的相關資料
-編碼未經測試，就整合到軟體中，導致整個系統崩潰
-誰都可以獲取專案資料
列舉的這些小問題，看起來都很「低階」，但小問題，一樣要命。就是不久前，乙個做大資料平台的同鞋跟我抱怨。專案組剛花了大量的精力修復了乙個高難度的bug，測試也通過了，上線後，居然原來的bug又出現了。活見鬼!專案經理的**都快被客戶打爆了。大家又搞了三天才明白，原來是版本弄錯了……
實操層面，我們應該參考能力成熟度模型整合cmmi裡，對配置管理的實踐要求。畢竟cmmi**於全球頂級軟體企業的優秀實踐整合。
綜合以上，對配置管理做乙個系統梳理：
目的：在軟體專案生命週期中，維持工作產品的完整性和一致性，減少由配置問題引起的混亂，提高軟體開發生產率，降低成本。
核心：管理變更
關鍵實踐：
- 最簡易的配置管理——版本控制
- 配置管理策劃
- 軟體專案中到底什麼應該受控——配置項
- 符合專案需求的配置管理系統
- 建立和發布baseline
- 配置管理真正的核心過程——跟蹤和控制變更
- 軟體開發過程的「庫存盤點」——配置項狀態報告
- 配置和qa的深度合作——配置審計
配置管理既然能夠完整覆蓋整個軟體生命週期，以及所有重要的工作產出，可見配置管理並不是配置管理員乙個人的事，而是與所有專案成員息息相關。它通過工作產出，將過程管理與人員管理關聯起來。真的不能小看它哦~不然……
資料 配置管理
目前國內外常見的10種配置管理工具一覽 配置管理不是單純的指軟體的 版本管理,上面的資料介紹的主要是 級管理.配置管理的目的是為了準確交付，減少事故.當專案本身是由多個語言，多個部門來開發，採用了較多開源和第三方的軟體例項時，需要好的配置管理.配置管理之路 scmroad 軟體測試網 軟體測試管理 ...
cmmi配置管理
配置管理的目的是通過執行版本控制 變更控制等規程，以及使用配置管理軟體，來保證所以配置項的完整性和可跟蹤性。配置管理是對工作成果的一種有效保護。凡是納入配置管理範疇的工作成果統稱為配置項 comfiguration item,ci 配置項主要有兩大類 屬於產品組成部分的工作成果，如需求文件 設計文件...
Zookeeper配置管理
zookeeper的的配置可以分為三種，單機，偽集群和集群，三者具體操作差不多 集群時無非就修改一下配置檔案 因為現在手上就一台伺服器，記錄一下單機模式，即一台伺服器既當leader，也當follower。step1 把zookeeper的tar包放在 opt目錄下 解壓。並把資料夾名改為zooke...