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

”

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

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

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

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

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

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

很多用戶會帶着各種各樣的需求和建議來找我們，有些是相互沖突的，有些則會産生意想不到的副作用。例如，有個團隊主管想進行一些字段調整，而那些根本用不着這些字段的團隊就會比較抵觸。最終我們對配置管理工具定制化的需求進行了分級，需求隻有經過了分級我們才去實現。

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

在這種增速之下，我們這個配置管理小團隊要做的事情一下子就多了起來。我們需要持續評審并改進以下三項内容：工具的可擴展性、流程、成本。多數工具的可擴展性其實相當容易理解：更多的用戶意味着更頻繁地産生更多的數據，因此，請确保你能夠：

3.對工具底層的數據庫及文件系統進行擴容，支持更大的并發量，同時還能夠滿足一定的性能。

說白了我們需要做的無非就是采用更牛掰的硬件，以及确保工具本身支持這種可擴展性。

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

構建的可擴展性又是另一碼事。更多的産品意味着需要維護更多的構建配置、運行更多的構建（以及保存構建記錄）。更大的代碼量也意味着更長的構建時長。再者，為了獲取更快速的反饋，用戶需要更頻繁的構建。因此挑戰可拆分為三個方面：硬件（更多的構建服務器）、軟件（一個健壯耐操、對用戶友好的自動化構建系統）、以及構建本身的速度。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!