網際網路敏捷開發配置管理策略思考
目前公司配置管理在策略上採用的是不穩定主幹（unstable trunk）模式，所有的專案都在同一主幹上進行修改，在每週上線後並沒有明確的stable分支版本，基本上是靠SCM人員手工拷貝程式碼來管理維護的。這就引起了很多問題：
1）、多個專案組開發人員都可能併發對同樣程式碼進行修改，造成了嚴重的程式碼衝突問題。例如張三修改了a.java並上QA測試伺服器，在QA測試過程中，李四也對a.java進行修改並上QA，李四的程式碼覆蓋了張三的程式碼。由於是SCM人員並不清楚程式碼衝突情況，這樣張三和李四的程式碼上QA很容易相互影響並很難查具體原因
2）、由於沒有明確stable分支版本，導致上QA、上生產只能採用增量更新，上QA、上生產出問題後的程式碼回滾很麻煩，嚴重影響了測試、上線效率。對於生產環境執行的程式碼的具體版本並沒有明確的管理，導致生產系統出問題後要排查問題也很難查。
3）、由於核心基礎包沒有與上層應用隔離，導致大家都會對核心包進行修改，修改後程式碼質量並沒有有效控制。於是出現因為修改基礎包影響整個系統功能等現象
類似的問題很多。要在新的專案實施及後期運營中避免類似問題的重現，至少要從如下幾個方面來：
1）、分支管理策略：採用適當的分支管理策略來保證開發庫、測試庫、釋出庫的隔離
2）、適當引入每日編譯、持續整合、Code Review等敏捷開發的最佳實踐
3）、採用自動化指令碼完成上QA、上生產的部署工作，避免人工失誤
4）、對核心框架、後臺應用、前端頁面開發採用不同的配置管理策略
1、分支策略（Branching Strategy）
1）、不穩定主幹策略（The unstable trunk strategy）
此種分支策略使用主幹作為新功能開發主線，分支用作釋出。此種分支管理策略被廣泛的應用於開源專案。比如freebsd的釋出就是一個典型的例子。freebsd的主幹永遠是current，也就是包括所有最新特性的不穩定版本。然後隨著新特性的逐步穩定，達到一個釋出的里程碑以後，從主幹分出來一個stable分支。freebsd是每個大版本一個分支。也就是說4.x，5.x，6,x各一個分支。每個釋出分支上只有bug修改和現有功能的完善，而不會再增加新特性。新特性會繼續在主幹上開發。當穩定分支上發生的修改積累到一定程度以後，就會有一次釋出。釋出的時候會在穩定分支上再分出來一個
release分支。
此種分支管理策略比較適合諸如傳統軟體產品的開發模式，例如微軟Windows開發，對於網際網路開發不是很適合。已經在主幹上整合的新功能，如果達不到里程碑的要求，穩定分支就不能建立，很有可能影響下一個釋出的計劃。還有一個問題就是bug修改必須在各個分支之間合併。
2）、穩定主幹策略（The stable trunk）
此種分支策略使用主幹作為穩定版的釋出。主幹上永遠是穩定版本，可以隨時釋出。bug的修改和新功能的增加，全部在分支上進行。而且每個bug和新功能都有不同的開發分支，完全分離。而對主幹上的每一次釋出都做一個標籤而不是分支。分支上的開發和測試完畢以後才合併到主幹。
這種釋出方法的好處是每次釋出的內容調整起來比較容易。如果某個新功能或者bug在下一次釋出之前無法完成，就不可能合併到主幹，也就不會影響其他變更的釋出。另外，每個分支的生命期比較短，唯一長期存在的就是主幹，這樣每次合併的風險很小。每次釋出之前，只要比較主幹上的最新版本和上一次釋出的版本就能夠知道這次釋出的檔案範圍了。
此種分支策略的缺點之一是如果某個開發分支因為功能比較複雜，或者應釋出計劃的要求而長期沒有合併到主幹上，很可能在最後合併的時候出現衝突。另外由於對於每一分支都要進行測試才能夠合併到主幹中，測試工作量較大。
3）、敏捷釋出策略（The agile release strategy）
此種模式在採用敏捷開發模式（例如Scrum）的專案中廣泛採用，這些專案有固定的迭代週期（例如Scrum中每個Sprint的兩週時間），新的功能開發都在Task branch(Feature branch)上進行，在接近迭代週期的釋出階段時候，新建Release branch來完成本迭代週期的釋出，各Task branch(Feature branch)的功能merge到Release Branch中。在完成釋出後，Release branch的功能merge到Trunk和尚在進行的Task branch中。
採用敏捷釋出策略要求主幹的版本：
- 任何時候都可以釋出 ：在任何時候，產品所有者都可以基於主幹的最新版本，釋出新版本的產品
- 希望儘早釋出
此種模式較適合敏捷開發軟體的要求，但對程式設計師及SCM要求較高。
2、配置管理策略
根據目前公司的實際情況，建議採用穩定主
幹策略為主（The stable trunk）。參考淘寶網最佳實踐之ABS自動編譯 可以看到，淘寶也採用了類似的版本管理策略。
具體操作策略如下（尚需要細化）：
1）、trunk保持穩定，保證可以隨時釋出。trunk只有SCM人員才具有寫許可權，開發人員等只有讀許可權。
2）、為降低SCM分支管理的壓力，branch的許可權可以授予給指定的幾個組長
3）、在每一個專案開始前，採用Branch per feature(Branch per Task)的分支管理模式（Common Branching Patterns），由各組長或SCM人員按照branch管理規範建立對應專案的開發分支development branch，例如airline_product1_feature_leader_date、airline_product2_bug_leader_date。
專案定義：新功能開發、bug修復、需求變更等
4）、在每週的上線釋出後，在主幹建立基線release版本（通過svn tag），以當前的主幹作為基線，建立下一發布週期的test branch
5）、開發人員在所在專案的development branch完成開發及整合測試後提交上線單，由SCM人員根據專案上線單的分支名稱merge分支程式碼到本釋出週期的test branch，進行測試。如果在測試過程中有新的上線單且有可能與其他上線單存在衝突，則在merge到test branch的過程中，SCM人員可以很容易及時排查問題。
只要對上線單命名按照規範進行定義（例如與分支名稱相同），此部分工作可以由指令碼來自動化，存在衝突再人工干預。
6）、測試人員完成本釋出週期test branch所有上線單的功能測試後，由SCM人員將本釋出週期的test branch合併到trunk，並通過打tag來release 一個上線版本
7）、系統人員利用自動化部署指令碼從trunk檢出對應的release版本進行上線部署
此部分工作採用自動化指令碼完成，自動化指令碼主要完成如下操作：從trunk檢出完整的release 版本並打包，幷包含部署包的md5驗證碼-> 上傳部署包到生產系統各伺服器->校驗釋出包的md5驗證碼是否正確,保證檔案正確傳輸->完整備份生產系統的執行包->部署生產系統
8）、每日晚上對trunk進行持續整合，保證能夠正常編譯和部署。工具建議採用hudson
9）、對於核心程式碼及後臺程式碼的修改，採用Pre-commit review模式，必須通過code review後，才能夠提交到trunk中。工具可以採用reviewboard
10）、其他一些值得討論的問題
開發分支的生命週期問題：上線後，原有的development branch變為只讀的或者可以定期刪除掉。
緊急上線策略：緊急上線不遵循每週兩次的上線週期，因此對於需要緊急上線的程式可以從trunk檢出最近的release版本程式碼建立臨時測試分支（test branch），緊急上線仍然需要按照規範建立對應的development branch，然後與臨時測試分支合併，測試通過後上線，同時由SCM人員將緊急上線的development branch合併到當前的測試分支，繼續進行測試。
不同專案的配置管理策略：對核心框架、後臺應用、前端頁面開發可以採用不同的配置管理策略，例如核心框架可以採用不穩定主幹策略（The unstable trunk strategy）；後臺應用採用穩定主幹策略（The stable trunk）
3、版本控制工具選擇
SVN的集中管理模式較為適合目前公司協作開發的需要，例如SVN所提供的集中式許可權控制，對程式碼、二進位制檔案及文件的集中管理，類似TortoiseSVN的支援工具以及Eclipse 外掛等。而Git/Mercurial（hg）的分散式管理特性，很適合開發人員本地版本開發管理。
因此可以結合SVN和Git/Mercurial（hg）來作為版本控制工具。用SVN進行集中管理，用Mercurial（hg）在多個不同機器上進行開發，功能完善並測試完成後再提交至 SVN Repository。可以藉助git-svn、HgSubversion、hgsvn這樣的工具來結合使用。考慮到目前的開發環境為Windows環境，建議採用Mercurial。
值得一提的是SVN從1.5版本開始，對branching merge的支援有很大的提升，大大簡化了分支合併的難度，可以參考What’s New in Subversion 1.6?。
4、一些工具
code review
持續整合
自動部署
商業軟體中採用atlassian的系列產品倒是不錯的選擇：Jira+Crucible+FishEye+Bamboo