謹以此文獻給在中小規模的軟體公司中，希望向配置管理方向發展的朋友。
用幾個小故事，展現配置管理在軟體公司中的發展過程，同時，也是配置管理員在公司中的發展之路。為了展現主線，故事都比較概括，且本文側重於配置管理的發展，所以很多與配置管理相關的具體工作都被省略掉了。
故事一：配置管理出現
h公司是一家成立不久的小公司，主要業務是開發客戶定製的軟體。專案a是該公司承接的第乙個規模超過10個人的專案。專案進行到測試階段時，專案經理發現專案組中經常出現已修改的bug重現，應該提交的**沒有提交，或者提交的版本有誤等問題，白白耽誤了很多時間，專案經理為此非常苦惱，在經過多方求醫之後，最終認定是配置管理方面的問題。
專案經理再經過與高層領導商討之後，為專案組增加了一名配置管理員。配置管理員到專案組之後，規範了配置管理工具的使用、工作成果的提交及發布機制，雖然增加了部分工作量，但有效解決了專案組的問題，且解決問題之後節省的時間大大超過了增加的工作量。
故事二：配置管理發展
鑑於專案a在沒有配置管理員之前出現的種種問題及有了配置管理員之後的效果，在接下來的專案b中，專案經理從專案開始時就爭取到了配置管理員的名額，並希望可以從根源上解決專案a中出現的問題。配置管理員到位之後，與專案組成員一起，優化了在專案a中使用過的流程，使之更貼合專案b的實際情況，並制定了需求、設計等工作產品的配置管理規範。有效防止了專案a中出現的問題的重現。
故事三：異地開發的配置管理
專案b結束之後沒多久，專案c就開始了，因為客戶要求駐場開發，但是又沒有足夠的空間容納所有的專案組成員，所以與客戶商定之後，決定一部分功能在公司開發。因此，配置管理員與專案組一起制定了配置庫互動方法：每天通過郵件互相傳送配置庫的新增內容。過程中也有人提議用vpn的方式，但是因為公司中使用vpn訪問配置庫的速度太慢，所以不得不放棄。過程中採用的配置管理規範與專案b類似，唯一不同的就是每天兩邊配置庫的合併。
故事四：多分支專案配置管理
隨著公司業務的開展，公司做了越來越多的類似的專案，這時，公司領導發現，如果能把這些專案中共通的東西拿出來做成平台，那效率一定會提高很多，所以成立了平台專案組。現在公司的所有專案都有配置管理員，很自然地，平台專案也擁有了自己的配置管理員。鑑於平台組要為很多專案提供開發平台，且採用迭代方式開發，功能在不斷完善，且每個迭代都會有新的版本發布，所以配置管理員重點進行了分支和發布方面的管理。
故事五：組織級配置管理
雖然絕大多數的可以重用的技術都納入到平台中，但是專案的一些文件性的東西以及專案組特有的沒辦法納入平台組的技術還是時有流失，為了保住這部分資產，公司決定建立組織級配置庫，並期望該配置庫解決上面所說的問題。但是組織級配置庫中的內容量多，而且很雜，完全脫離了配置管理的範疇，進入了檔案管理的範疇，所以公司現有的配置管理員都一籌莫展，希望公司可以招聘精於檔案管理的人員進行管理。
故事發展到這裡，在中小軟體公司中，配置管理的發展基本上就到頂了，剩下的工作是怎樣優化各類專案中的配置管理及組織級配置管理，以充分發揮配置管理的作用。
非常道 中小軟體公司專案管理
前言 從事軟體開發專案管理工作多年，經歷過英雄輩出的wps cced時代，也看到了蜂擁而上進行進銷存軟體開發的瘋狂，一路走到web2.0的時代，目睹那些為軟體開發而奮鬥的各類公司，在中國這個太有特色的市場裡，不停的在我眼前幻滅 崛起，我一直在想為什麼沒人去拍一部it人題材的電影，似乎我們這個行業有點...
Tomcat配置管理員賬戶
每次訪問本地tomcat服務裡面的專案都要輸入一大串路徑，費時耗力還經常出錯，本著能少乙個單詞就絕不多寫乙個字母的思維，來解決一下這個問題。開啟apache tomcat 7.0.42 conf目錄下的service.xml 大概在70行左右，把預設8080埠改為80，順便把字符集也設定一下 開啟a...
tomcat配置管理員 走後門
tomcat不僅僅是乙個servlet容器，它也具有傳統的web伺服器的功能 處理html頁面。但是與apache相比，它的處理靜態html的能力就不如apache。可以將tomcat和apache整合到一塊，讓apache處理靜態html，而tomcat處理jsp和servlet.這種整合只需要修...