945
《配置管理最佳實踐》——2.4 建立構建職能的注意事項
本節書摘來自異步社區《配置管理最佳實踐》一書中的第2章，第2.4節，作者： 【美】Bob Aiello , Leslie Sachs著，更多章節內容可以訪問雲棲社區“異步社區”公眾號查看
2.4 建立構建職能的注意事項
根據我的經驗，在開發團隊中實施構建工程最佳實踐之前，必須要打消大家的疑慮。有時，對現有構建過程複雜度認識不足，可能會導致人為錯誤、代碼缺陷、不斷返工、生產效率低等問題。造成這種現象的大部分原因都是技術上的，另外可能是過程上的。而一旦有問題，就會有人把責任推到構建過程上來，建議簡化構建過程。曾經遇到過在某產品中使用的技術特別複雜，而專業技術人員深陷於複雜的技術泥潭之中，並把它弄得更複雜了。顯然，我們都希望盡可能地把事情變簡單，做到萬無一失。但是現實情況是，很多專業技術人員都想通過能處理複雜問題來顯示他們的實力，結果把問題弄得更複雜了。
2.4.1 推廣獨立構建
獨立構建可以驗證代碼庫中基線的配置項。通常監管部門都要求有獨立構建，以降低任何可能帶來問題的風險。也就是說，構建工程師要說服開發團隊改變一些構建過程，來避免可能出現的錯誤。開發人員認為構建工程師從頭開始重新構建一遍應用太浪費時間。也許開發團隊知道在產品被提交到QA或者生產環境之前要通過獨立的環境進行構建是監管的要求，但是很多工程師還是會竊笑，覺得這項任務就是浪費時間。如果構建工程師是開發團隊中的一員，這將有助於理解構建當中涉及的技術問題，但是這樣常常會把自己放到一個尷尬的位置。很多時候，構建工程師都要和開發團隊進行妥協。總之，管理層應該在公司規章製度允許的情況下，讓構建工程師可以盡快地得到他們想要的信息。構建過程要盡可能地快並且自動化，這樣其他人不需要等很長時間就能得到想要的東西。為了做到這一點，構建工程師應該負責第一時間查看和解決構建中的問題。
在構建的工作中經常會遇到的問題是構建過程過度工程化，導致構建過程太複雜。通常情況下，公司有一些工作已經自動化了，但是其中仍有很多讓人頭疼的部分，以致沒有一個人懂得這個構建到底是怎麼工作的。這就導致公司裏的其他人不敢修改，更無法提供支持。通常來說，這就是構建過程過度工程化的直接結果。下一節，我會分享我是如何解決這個問題的。
2.4.2 過度工程化構建
我發現很多公司不可靠、太複雜的構建工程已經嚴重阻礙了其開發工作。接連不斷構建失敗警示我們這個團隊可能無法成功地發布一個版本，這成了項目和公司最大的風險。有時候這都是由於軟件配置管理做得差或者幾乎沒起到配置管理的作用導致的。但是更多時候是因為構建腳本本身太複雜，幾乎無法維護造成的。通常的問題是一個很聰明的人創造了一套非常複雜的構建過程，團隊裏其他任何人幾乎都無法理解這套過程和自動化程序，更無法進行支持。常見的情況是，構建工程師嚐試使用構建功能時，他希望可以傳進去一個變量作為參數（例如，開發、QA或者生產三個值），這時就可以根據參數生成需要的配置文件。在第3章中，我們將會詳細介紹一些關於創建配置文件的最佳實踐。而開發者設計構建工具的時候，他希望相同的代碼可以運行在各個環境當中（例如，開發環境、QA環境和生產環境）。但是他基本上不了解軟件測試的過程，也不了解生產環境下部署和配置的情況。因此，軟件測試時用的是一個版本構建，而當我們把產品部署到生產環境下時，卻用了另外一個版本。這是一個很大的問題。我們一定要確保軟件測試和生產環境下使用的是同一版本的源代碼，例如都是從基線發布出去的。但為每個環境都重新構建，這顯然是不現實的做法，因為這種情況下可能繞過IT的控製，而且沒有進行一致性評估。還有一個常見的問題就是，在構建過程中同樣的文件被放到不同地方，名字一樣，但是大小卻不一樣。這會讓看到的人相當費解。之所以那些聰明勤勞的工程師開發出來的係統這麼複雜、這麼難理解，是因為他們根本沒有從軟件測試的角度考慮需求或者不理解這個工具的本質需求。
2.4.3 保持正直和誠實
有些時候, 公司管理層要求做的事，並不都是完全正確的。一次，某大銀行要求我保證所有的開發團隊都是符合2002版薩班斯法案404節IT監管要求的。在這種情況下，我的責任是審查所有團隊，要求所有開發團隊都要依據ISACA1Cobit2模型的要求，建立合適的變更和配置管理流程。這項工作對於我這種配置管理狂熱分子來說是再興奮不過的事了，我幫助他們滿足了合規要求的同時，還提高了產品的質量和工作效率。我在項目最後階段也加入到了這個項目。項目要在一段很緊張的時間內完成SOX法案3的合規要求。這時我的老板，SOX法案的合規專員和我一起開會，當我提出要為每個團隊做配置管理評估的時候，他們都非常吃驚。他們認為審查是否符合SOX法案才是第一位的。這一次雖然他們有些不了解我的做法，但是我成功地說服他們同意我去做配置管理評估。評估結果是四分之三的團隊都使用了正確的軟件配置管理流程。然後我請求給予更多的時間進行審查，最終的結果是他們都是合規的。六個月後再次做審查時，我發現一些團隊已經倒退，重新拾起了先前的做法。我覺得這已經不是技術能解決的問題了，而是一個辦公室的政治問題，所以我最終離開了這個公司。不久，這個大型金融服務公司就倒閉了。我覺得倒閉的原因在很大程度上是公司短視，太關注短期目標，偷工減料，最終釀成了災難。就如同當年的安然事件一樣，但是我會盡力讓公司做正確的事情，並符合所有行業法規。
2.4.4 隸屬研發部門引起的利益衝突
另外一個實例是，研發團隊的頭兒是我的直接領導，而我幫助團隊構建和部署一個大型的國際貿易係統。這個係統用的技術十分複雜，因為我和研發團隊一起工作，理解這個係統的速度快了很多。我們一遍又一遍地構建、發布和部署交易係統，從未發布和部署過失敗的構建。然而，項目截止日期日益臨近，甚至都已經發展到按時發布產品和研發部門經理獎金掛勾的情況。研發團隊不斷地修複缺陷，然後構建，最後部署上去，一遍又一遍地進行著。上線的截止日期到了，我卻被要求去部署一個因含有缺陷而未經過QA團隊核實的係統。也就是說，我們測試了係統的某個版本A，並得到QA團隊的批準，可以進行部署；但是實際上我們部署的卻是另外一個版本B。我找到研發部門的頭兒，也就是我的直接領導，解釋說我們不能構建和部署一個未經QA團隊批準的版本。他當然不希望因為錯過最後期限而丟了豐厚的獎金，所以他堅持發布這個版本。無可奈何，隻好找到他的直接老板並解釋了事情的原委。他的老板當即表示，最新的版本應該走正常的測試流程，必須要經過QA團隊的確認才可以上線。因此，項目延期兩個星期，但是我們遵守了正確的流程，避免了上線後可能出現的問題。可是從此以後，這個研發團隊的頭兒覺得我是在和他對著幹，而不再配合我，我的工作也就變得很難進行下去了。
2.4.5 組織結構的選擇
在理想的情況下，構建工程團隊應該向足夠高級別的管理層匯報，避免自己受到辦公室政治和那些隻關注自己利益經理的影響。經常看到構建團隊是QA團隊的一部分，但是遠離開發團隊會阻礙交流合作，以致無法快速有效地理解要構建的係統。因為在部署應用程序的時候我的職責和係統管理員（SA， system administration）的職責有些重疊，所以我需要同時向係統管理部門和數據安全部門的經理匯報。還有很多其他的組織結構，但是無論哪種組織結構，都要確保構建工程師可以得到他們所需要的信息，經授權後可以去操作，以便有效地保護公司的資產。同樣重要的是，構建工程團隊負責人應該是一個遇到問題願意去溝通的人，如果有必要，也是敢於說不的人。比如版本中還有嚴重的問題沒有修複，在這種情況下就不能發布版本給客戶。我個人的經驗是，構建工程師是一個十分具有挑戰性的職位，需要高級管理層提供必要的支持，以便構建工程團隊可以做好自己的本職工作，保護好公司的重要資產。
1信息係統審計與控製協會（ISACA，Information Systems Audit and Control Association）是全球公認的信息科技管治、監控、保安以及標準合規的領導組織。
2COBIT(Control Objectives for Information and related Technology) 是目前國際上通用的信息係統審計的標準，由信息係統審計與控製協會在1996年公布。這是一個在國際上公認的、權威的安全與信息技術管理和控製的標準。
3SOX即《薩班斯法案》（Sarbanes-Oxley Act）的簡稱。 薩班斯法案是美國政府出台的一部涉及會計職業監管、公司治理、證券市場監管等方麵改革的重要法律。薩班斯法案為公眾公司的外部審計師創建了一個新的監督體製，並把對財務報告的內部控製作為關注的具體內容，不僅要求管理層報告公司對財務報告的內部控製，而且要求外部審計師證實管理層報告的準確性。
最後更新：2017-06-05 10:01:46