演進配置管理的七條經驗

隨著人員規模、產品數量、釋出頻率的急劇增長，配置管理的各個方面將面臨若干挑戰和機遇。本文將為你呈現當組織處於上述階段時會面臨的幾個主要問題，以及需要對流程和工具所做的改進。

2004開始我負責帶領我目前所處公司的配置管理團隊，而這也是一項讓我十分起勁的工作。我將在本文中分享一些個人經驗，希望有助於讀者迅速成長為配置管理老司機。

一開始我們只是個小公司，擁有約40名調研、開發人員，兩條產品線，釋出週期也很長。此時我們的配置管理相當的簡單：一個當時流行的原始碼管理軟體，一個老舊的、幾乎沒人用的缺陷跟蹤工具，以及一些可讀性像鬼畫符一樣的shell構建指令碼。由兩名配置管理工程師組成的團隊足以應付一切。

一年過去了，公司業績良好，僱員數量也穩步上升。所幸的是我們團隊只需要確保軟體有足夠的license分配給新員工即可，管理層無需為配置管理爭取更多的預算。由此得出我的第一條經驗：

1.管理者僱用更多開發人員時需要注意由此產生的配置管理相關的開銷。

我們配置管理團隊遇到的第一個挑戰就是那個缺陷跟蹤工具。該工具已不再維護，也沒法購買更多的license，再加上其巨難用、幾乎無法定製化的劣勢，尋求替代已迫在眉睫。我們很“理所當然”地把目光投向了我們原始碼控制工具的供應商所提供的一個先進的缺陷跟蹤工具。該工具本身比較昂貴，配套的硬體升級進一步增加了使用成本，但我們有足夠的預算，事實也證明了我們是做出了一個多麼英明的決定。採用了該工具後，報告跟蹤缺陷、生成各種報表、定製化資料和業務邏輯，這些工作忽然變得非常輕鬆。由此得出的第二條經驗：

2.工具的定製化必須納入管控。

很多使用者會帶著各種各樣的需求和建議來找我們，有些是相互衝突的，有些則會產生意想不到的副作用。例如，有個團隊主管想進行一些欄位調整，而那些根本用不著這些欄位的團隊就會比較牴觸。最終我們對配置管理工具定製化的需求進行了分級，需求只有經過了分級我們才去實現。

幾年後我們被一家大型企業收購，此後事情就變得非常有意思。我們開始開發新產品，併為現有產品新增大規模的新特性。調研開發人員急劇擴充，人員規模有時甚至能在一個月內增加10%。

在這種增速之下，我們這個配置管理小團隊要做的事情一下子就多了起來。我們需要持續評審並改進以下三項內容：工具的可擴充套件性、流程、成本。多數工具的可擴充套件性其實相當容易理解：更多的使用者意味著更頻繁地產生更多的資料，因此，請確保你能夠：

3.對工具底層的資料庫及檔案系統進行擴容，支援更大的併發量，同時還能夠滿足一定的效能。

說白了我們需要做的無非就是採用更牛掰的硬體，以及確保工具本身支援這種可擴充套件性。

由於我們所使用的的原始碼控制工具和缺陷跟蹤工具本身就是商業版的，我們只需要對伺服器硬體進行升級。與其對硬體進行多次小幅度的升級，我們決定一次性採購一些特牛掰的伺服器以支撐我們未來五年的需求。直到現在我們依然覺得我們當時又做出了一個多麼英明的決定，在那以後我們不再需要定期清理空間或排查效能問題，給我們留出更多時間去處理其他事情。順帶一提，儘管有些工具會存在先天的效能問題，在多數情況下采用效能足夠強勁的硬體便足以彌補(不幸的是這一點被一些缺德的供應商濫用了)。歸根結底，我們建議你採用預算所能支援的最強勁的伺服器、最快的儲存，儘管最初會顯得殺雞用牛刀，但長期來看是划得來的。

構建的可擴充套件性又是另一碼事。更多的產品意味著需要維護更多的構建配置、執行更多的構建(以及儲存構建記錄)。更大的程式碼量也意味著更長的構建時長。再者，為了獲取更快速的反饋，使用者需要更頻繁的構建。因此挑戰可拆分為三個方面：硬體(更多的構建伺服器)、軟體(一個健壯耐操、對使用者友好的自動化構建系統)、以及構建本身的速度。

在硬體方面，我們需要大約十臺新的構建伺服器，而虛擬化技術在此派上用場了。與其採購並維護十臺物理機，我們採購了一臺效能特牛掰的伺服器，配置了大量的高速儲存，在上面部署了十臺相同的虛擬機器作為構建伺服器。除了能夠節省長期的硬體成本，我們還可以定期獲取快照來便捷地管理構建環境。假如一次軟體升級(甚至是一個使用者)意外搞崩了構建環境，我們可以透過回滾到最近的快照來恢復。由此帶來了下一條經驗：

4.將構建環建納入管控非常重要，特別是當你有多個構建伺服器時。

更牛掰的硬體不足以顯著降低構建時長。但擁有了多臺牛掰的構建伺服器後，我們可以執行並行的分散式構建(無論是透過編譯器本身的特性還是第三方工具)。這是一項持續性的努力，時至今日我們仍在設法改善構建時長，例如透過降低程式碼間的依賴來提高構建的並行執行性。

在軟體方面，我們棄用了那些老舊的、可讀性差的構建指令碼，取而代之的是我們自行開發的一個圖形化介面的構建工具，利用該工具我們可以輕鬆地配置並執行定時構建，無需人工介入。我們還為一些開發人員提供了培訓，使得開發人員沒有配置管理團隊的介入也能自行使用工具來執行各種構建任務。這些舉措在當時而言已經足夠了，而在今天看來我們所開發的工具是有其侷限性的，該工具缺少一些開發成本高昂的特性，維護起來也耗時不菲。我們現在已經改用了第三方的持續整合工具。

在我看來，投資在自研的配置管理工具在長期來看是行不通的。我的結論是：

5.當組織規模還小時就開始採用現成的第三方工具。

儘量避免自行編寫工具，因為最終你得不斷迭代你的工具，重複去造那些第三方工具的輪子。

這些年來我們的開發流程也有了顯著的改變。我們僱用了背景、經驗不盡相同的開發人員，為此我們需要不斷提高流程的健壯性，確保大家都能按正確的方式開展工作，同時也有利於更頻繁、更快速的構建。

另一個顯著改變的就是分支策略。當我們的規模還比較小時，幾乎所有開發者都是直接將程式碼提交到活躍主幹上。當採用了每日構建後，我們需要嚴格把控每一次的提交，否則構建將會一直失敗。越多的開發人員也意味著非期望的變更越有可能引入到每次的構建中，有時甚至在產品釋出後才被發現。而現在每個開發人員都工作在私有分支上，每個團隊都有一個整合分支，只有當團隊長評審過分支內容後才將其合併到主幹。

有一個全新的需求就是要建立起變更項(缺陷或任務)、程式碼、構建這三者之間的可追溯性。當我們的規模還小時我們僅跟蹤嚴重缺陷，開發人員自己記錄在何時何處變更了什麼內容，然後每一兩個月構建一次。而現在我們擁有了超過一百名開發人員，每人每週負責處理若干個缺陷和任務，所有產品每天會構建多次。特性的交付，缺陷的修復，這些都不能再指望依靠開發人員來自行把控了。因此我敢說：

6.當開發人員超過一定數量時可追溯性是道必須要邁過去的坎。

我們設法將原始碼控制、問題跟蹤、構建系統整合起來，結果就是當前我們每次程式碼提交都會關聯上一個問題跟蹤單，構建系統會將構建資訊更新到對應的跟蹤單上。我們還在嘗試整合更多的內容，諸如需求和測試。

最後需要提及的一點是軟體的成本。當使用者量大時很多商業軟體會貴得離譜，不僅僅是license，還包括管理成本、硬體配置以及其他亂七八糟的隱性成本。早前我們就決定替換掉我們的問題跟蹤工具，純粹就是因為license和維護成本遠超其他同型別工具。幾經評估過後我們發現了一個替代品，各方面比原有的工具更完善，成本還足足低了三十倍。由此得出的經驗是：

7.持續評估評估你所使用的工具與市場上所提供的工具的成本對比情況。

我們也在評估是否需要替換掉我們當前所使用的、昂貴且略顯過時的原始碼控制工具，畢竟這幾年軟體市場已經有了長足的發展了。

在一個成長中的公司負責配置管理的工作充滿了挑戰性，同時也很有意思。關鍵是要懂得提前規劃。當你明確了目標和那些需要規避的坑後，你將更加遊刃有餘。