73
《配置管理最佳實踐》——1.6 工具的選擇
本節書摘來自異步社區《配置管理最佳實踐》一書中的第1章，第1.6節，作者： 【美】Bob Aiello , Leslie Sachs著，更多章節內容可以訪問雲棲社區“異步社區”公眾號查看
1.6 工具的選擇
在實施任何一個源代碼管理解決方案中，工具的選擇都是一項非常重要的任務。選擇一個源代碼管理工具需要考慮眾多的因素。針對這一主題，我會在這章隻討論最基本的方麵，而在我們的網站上（www.cmbestpractices.com/tools）專門講了一個工具的選擇部分作為對本章的補充。這樣一來，就可以保證內容的時效性，同時可以允許我的同事說出他們的觀點，盡管很多時候這個題目都會變成激烈的宗教般的爭論。
首先可以觀察到的一個事實是，目前市場上有眾多優秀的源代碼管理工具。感謝廠商們開發了如此眾多商業的和開源的優秀源代碼解決方案。我的經驗是，所有的工具供應商都值得讚譽，因為他們不僅僅關注短期的銷售產品的目標，還關注開發和傳承高效的最佳實踐。即便是一些“不好”的工具在某些特定的情況下都有它們的地位。最重要的事情是開始評估自己的源代碼管理解決方案的需求，然後以開放和務實的態度去評估哪些解決方案最符合團隊正在做的工作。所有的源代碼管理工具都是不一樣的，也就造成了某些工具在某個特定項目中可能會表現得好些或者壞些。一些工具的功能不是很豐富，可集成到一起的其他工具也不是很多；而另外一些可能學習曲線很陡峭，可一旦用戶接受了全麵培訓和得到支持，工具就會體現出巨大價值。
許多常用的源代碼管理工具最大的問題是缺乏測試和控製代碼庫自身內部完整性的能力。例如，我就看到過在一些非常著名的源代碼管理工具中，代碼沒有任何跡象就直接丟失了。在工作過的某大型金融服務機構中就發生過這類問題，代碼丟失導致公司蒙受了重大損失。
在開源軟件和一些大型知名廠商的商業軟件中，都出現過類似的問題。因此，把金融交易係統的源代碼放在這樣的工具中也許不是一個萬無一失的方法。最好的方法是，保留額外一份代碼的備份，以便用來構建和發布產品。
下麵是在選擇源代碼管理解決方案時應該考慮的方麵：
容易使用（相對於學習曲線來說）
具有分支的能力
代碼合並（圖形界麵和命令行都支持）
變更曆史
建立基線（例如標記和標簽）
變更集
管理工具（例如可檢查代碼庫的完整性）
成本（包括總擁有成本）
有效的培訓和支持
與常見IDE 的集成
完整的 ALM解決方案（相對於與第三方工具的集成）
良好定義的使用模式
開源軟件與商業軟件
產品成熟度
供應商承諾
可擴展性和開放的API
實施的時間和成功的風險
一開始最重要的是定義選擇有效配置管理解決方案的目標。然後，通過上麵提到的和其他未提到的方麵來選擇合適的源代碼管理解決方案。有時候基於僅僅一項或者多項標準就可以排除某個工具。例如，很多公司的開發團隊非常大（數百名到千名）分布在全球各地，包括美國、歐洲和亞洲各地。在這種情況下，源代碼管理工具真正顯示出了其價值所在，因為它可以幫助保護代碼、組織開發工作，並且可以知道團隊每天都在做什麼。有時，當團隊真正需要更強大的工具提供某些高級功能的時候，就需要提前規劃好必要的培訓和支持。在某些公司，需要在同一代碼庫中支持多個變體，這就要求工具必須支持複雜分支和代碼合並。
隨著更改的增多，查看所有更改的曆史記錄很快就會變得很複雜。大多數公司都需要能夠很容易地查看這些曆史記錄的功能。所有的開發團隊都要有建立基線的能力。在某些有IT控製和法律合規監管的公司，這是一項基本的要求；相反，在我讀研究生做課後作業時，建立可靠基線就不是那麼重要了（雖然那時我也使用源代碼管理工具）。例如，如果期望一組確定的變更可以很容易地應用到（此分支）或者回滾時，那麼變更集是非常有用的，哪怕這僅僅影響到你是否可以按時交付作業。許多組織也非常看重是否有一個可靠的供應商或者開源社區支持這個工具。
1.6.1 開源軟件與商業軟件
在選擇工具的時候，我們還應該考慮公司在開源和商業配置管理工具上是否有強烈的偏好。哪一種類型的工具都有優點和缺點。一些開發人員認為開源軟件好，因為源代碼是可見的，而且有活躍的用戶社區在開發更多的功能；而商業軟件的擁護者則認為商業軟件的支持和功能更好些，因為有一個很大的專職研發團隊在開發這個軟件，通常這意味著可以從一個技術一流的公司得到支持。還有一種結合了上麵兩種方法的情況，即商業軟件供應商願意對所有人公開自己的源代碼，並且允許他人可以通過定義好的API寫代碼來拓展功能。另外一種很流行的做法是提供一個免費的（或者不受任何限製的評估用）版本，其中某些功能或者許可證的數量是有限的。選擇商業或者開源代碼管理解決方案是一個非常有趣且很熱門的討論，雙方的很多看法都很有道理。針對這一點，在這本書的支持網站上有很多更深入的探討（www.cmbestpractices.com/tools）。盡管如此，我們還是要考慮公司對開源或者商業工具是否有某些強烈的偏好，公司裏的采購部門是否把它當作選擇工具的標準之一。
1.6.2 產品成熟度和供應商承諾
我曾經使用過很多在短期內幾乎很少有大改進的十分成熟的產品，既包括開源的也包括商業的。我也使用過很多采用了尖端技術的工具。工具太新了，以至於都沒有一個明確的安裝說明文檔。成熟的產品中，很少會遇到難題和使用問題，但是這些工具往往具備的高級功能也少，無法極大地提高程序員的工作效率。有時我們想提高工作效率但又不想在源代碼管理中太冒險，這時就需要在軟件成熟度與使用產品風險間取得平衡。在采用最新最好的源代碼管理工具集之前，一定要確認供應商已經做好準備，能夠且願意給你提供支持去維護這套先進的源代碼解決方案。
1.6.3 可擴展性和開放的API
當有同事想通過開放的API或者 shell 腳本去擴展或者修改源代碼管理工具時，我一般都勸他們不要著急，想好了再做。雖然使用腳本（例如觸發器）可以有助於強化流程，但是支持定製工具花費的時間和精力也是必須要考慮的。我看到很多寫腳本或者封裝工具的工作最後都慘敗了。通常最好是與供應商合作，製定出一個好的解決方案，然後和整個用戶社區共享。起初雖然沒發現自己寫的腳本有什麼問題，但是當開源社區使用並且給你提出很多意見和建議後，這些腳本就會變得更加可靠。如果你是唯一一個知道這些腳本如何工作的人，這對於你和你的公司都不是一件好事。
1.6.4 不要過度工程化源代碼管理
在配置管理中，我看到的最大的錯誤就是開發人員用心良苦過度地工程化源代碼管理工具。源代碼管理工具有許多很酷的特性，很多技術人員一看見就感到興奮，於是一旦開始工作就嚐試去自動化一切。有的時候，這會導致源代碼管理方案加進去很多花裏胡哨的東西，導致整個係統常常無法正常工作。如果整個係統因為那些花裏胡哨的東西而無法工作恰巧發生在負責的技術人員度假時，就會給公司造成很大的麻煩。把過程自動化，集成到源代碼管理工具中是不錯的想法，但這應該僅限於在自動化完成這項任務的情況下，不要添加更多其他的東西。源代碼管理解決方案應該體現敏捷和精益的原則，從而達到更好的效果。
例如，創建一個分支來支持一個缺陷修複是一個很不錯的想法，但是如果針對每個缺陷都要創建一個單獨的分支就會太複雜。實際上沒有什麼不可以違背的原則，但還是建議盡量保持你的流程精益，僅僅自動化那些十分必要的部分。
另外一個常見的錯誤是很多人寫腳本會在源代碼管理工具命令行外再封裝一層。這種做法的錯誤就在於用戶通常都不知道這個工具正在做什麼。因為腳本隱藏了工具的功能，常常替代了實際的培訓和清晰的流程。如果真的要寫腳本自動化源代碼管理工具，我建議腳本要清晰地顯示出每個執行的命令和命令的輸出情況，這樣就不會隱藏源代碼管理工具的實際操作。這樣的做法可以讓你清楚地知道腳本做了什麼，也有利於工具的培訓。對於成功地實施任何源代碼管理工具和能自動重複地執行任務的腳本，培訓都是最關鍵的因素。一定要確保能夠為團隊提供足夠的培訓，使他們了解如何充分利用配置管理工具。腳本不應該替代培訓，更不應該隱藏工具的功能。當腳本隱藏了工具的功能，開發人員就無法了解如何使用源代碼管理工具最基本的功能，而這常常會導致錯誤和降低工作效率；同時，還要有人維護和升級腳本，這通常是件耗時且易出錯的活兒，無論對於個人還是開發團隊都不是件好事。選擇合適的工具，使用模型和過程很重要，培訓則更重要。同樣重要的還有考慮影響交付優質產品的各個方麵，包括質量成本。
最後更新：2017-06-02 19:36:11