本文來自于 Rational Edge：構建管理通常是橫跨多個軟件開發規程，并且是易于出錯的，通過大規模的手工過程來執行。本文探究將關于大規模項目的構建管理活動自動化的方法，然后介紹 IBM Rational Build Forge 的自動構建及發布管理技術，以及改進的軟件質量技術。
對于希望在整個軟件開發生命周期中高質量且有效地構建軟件的組織來說，構建管理的領域是在最后的邊界之間。將軟件系統的所有部分裝配成可部署的、可使用的產品的過程需要許多步驟，并且涉及多個規程，包括開發、配置管理、測試和發布管理。雖然那些規程中的活動可能自動化程度很高，但是它們之間常常沒有相互作用。
在較小的項目中，這種缺乏跨規程的自動化可能不是使人虛弱的問題。但是當應用變得越來越復雜、跨平臺，并且是面向服務的，以及當團隊越來越大，并且是地理上分散的時候，當今簡陋的、且大量手工構建的過程開始被取締了，構建并測試產品的任務越來越不可預測，并且很難重復。成本和進度上的風險可以達到無法接受的水平。
大家公認的是，開發團隊經�；ㄙM大量時間來診斷構建過程中突然出現的錯誤 —— 有時候，比分離出錯誤的原因后對代碼進行修整所花費的時間還長。同樣，團隊經�；ㄙM過多的時間來維護并過分小心地對待他們的腳本驅動的構建系統。這種級別的人工干涉不可避免地妨礙團隊的生產力，并降低產品質量。問題是：對于這種情況能做些什么？
在本文中，我將著眼于現今的構建管理過程經常怎樣工作，并且探究在企業范圍內的開發工作中有效地將該過程自動化的幾種方法。最后，我將討論用于將任何大小的環境中的構建及發布管理自動化的 IBM® Rational® Build Forge™ 的重要能力。
更大、更好、更快、更多
遇到逐步上升的行業趨勢的沖突時，開發組織需要滿足似乎互斥的目標：即使是在軟件產品和軟件開發環境都更加快速地復雜化的情況下，還要增加產品質量，并加速向市場投放。
許多推動因素增加了這些困難，關鍵的是：
- 面向服務的架構（service-oriented architecture，SOA）和 web 服務的出現，它們可以集成多個、可復用的軟件組件，從而創建更大，更成熟的應用程序
- 法規遵循的增強，這可能要求詳細的跨開發生命周期的活動的審計記錄
- 分布式開發的大量增加，包括各種形式的外包，這作為一種減少成本，并壓縮市場投放時間的方法
由于這些和其他因素，開發團隊必須更加有效率、更加敏捷，并且更面向質量。這意味著提高軟件開發生命周期中過程自動化和集成的效率及有效性是不可避免的。越來越多的組織為了自動化而瞄準的領域是構建管理。
不難看出存在改進構建過程的一般需求。作為開發和發布管理規程之間的夾層，構建管理活動會因為現有工具集之間的裂縫而失敗。 每個規程都包括，將所有事情都放在一次構建中（開發、配置管理、測試、發布管理，等等），用其首選的工具進行活動，并且經常進行成熟、結構良好的過程）。但缺少的是跨所有規程集成的質量。這是成問題的，因為成熟的構建管理對整個團隊效率是至關重要的。如果您不能足夠頻繁地“改變不穩定的構建”，那么開發和測試都將遭受痛苦。
類似 IBM Rational Unified Process®（RUP®）的方法為跨規程的開發活動的協調提供了最佳實踐指導，但直到現在，也幾乎不存在可以幫助讓該指導應用于企業范圍的解決方案。
典型的構建管理缺點
許多構建管理系統本質上都是自制的，并且已經隨著時間演進了。團隊經常通過構建腳本來將它們的構建及發布過程自動化，然而，這些腳本驅動的系統很少適用于表現出現代軟件開發特點的日益大型、復雜，且分布式的環境。常常每個任務都獨立地運作，因此需要嵌入等待時間，并且適當地協調 —— 通常是手動地。在這種場景中，一個每夜都崩潰的構建可以很容易地說明，QA 人員只能在第二天閑坐著，失去了寶貴的測試時間，而開發和構建團隊卻在尋找錯誤故障。
當一個功能將可交付產品傳給其他功能時，經常出現錯誤的大的空白。每個規程中的團隊成員，通常都進行一些相對于其他規程來說有點自主的操作，在這種意義上來說，他們關注自己的核心能力，而不是他們的工作與整個產品構建過程之間的連接。因此，有時候當構建產品時，左手可能不知道右手在干什么。缺少一致、可重復的過程會導致構建再生成的困難。這在沒有充分地編制過程文檔的情況下特別突出，所以關于那些過程的知識僅掌握在一個或一些人手里。在分開的構建的情況下挑選每件東西效率非常低。構建結果很難解釋，而且要花大量時間找出錯誤。
同樣，腳本驅動的構建管理系統不能最優地利用構建服務器資源，因為，經常發生的活動是硬編碼的，以運行在具體的系統之上。同樣，硬編碼的腳本令過程更加難于改變，因此，可以將工作共享，或在分布式團隊中重新分配。如果知道“如何運行構建系統”的團隊重要成員離開了項目，那么項目風險將會大大增加。
開源的局限性
這么多開發組織依賴自制的、腳本驅動的構建管理過程的理由不是不存在將構建管理自動化的工具 —— 而是這些工具不提供足夠的可擴縮性。例如，許多開源的構建管理工具對小型項目很有效，這是他們設計的目標。舉例來說，對比分布的，多服務器的環境，他們一般適合單服務器。
那些已經試圖將這些工具的使用擴大到致力于多個項目的大型、分布團隊的組織發現它們總是在缺少一些方面，像過程控制、連接性和自動文檔化支持。為了企業開發環境而定制并維護這些系統所需的工作常常是很多的。（我個人覺得，一個企業開發團隊為了試圖使開源工具更加可伸縮得安排五個開發人員來重新構建這些工具。）這些活動增加了團隊必須執行的手工工作，并且占用了開發人員致力于關鍵業務的寶貴時間。最后，許多組織發現了局限性，大多數現成的構建管理工具最多將它們置于等同于自己動手的系統之上。
缺乏適當的工具已經證明是大型團隊采用更有效的實踐的絆腳石。要演進成有效的產品交付組織，您需要擴展您的企業的支持技術。類似的，您需要可審查的、可重復的、可靠的，您能夠編碼并在一個接一個項目中復用的過程自動化。為每個任務制作（并重新制作）您自己的工具所需的資源的消耗通常太大了。如果這樣的組織可以找到可接受的第三方工具來替代構建并維護定制軟件的話，那么成本和時間就會更有效了。
結構化方法的好處
更快速地創建更高質量軟件中的長期難題是需要平衡速度和效率（特別是在開發的情況下，創造性），使用一致、可靠的 —— 也就是，結構化的 —— 方法。
不論團隊的任務是開發、測試，或代碼控制，它們都不希望在如何操作上受到約束，特別是在工具的選擇上。他們的規程中的效率是極為重要的。 然而，從組織總體的更廣泛的角度來看，優化效率可能需要一些額外的結構。
例如，拿法規遵循的問題來說。像金融服務和衛生保健行業中的許多商家都承受著重大壓力，他們需要將在生命周期活動之內或跨生命周期活動如何行事，像開發軟件，編制成文檔。編制文檔占用時間，并需要交流，可能降低效率。但是制裁的風險對整個公司來說是重要的。您的團隊能夠生成準確描述該團隊如何構建一個一年前發布的產品的文檔嗎？該團隊可以在法規遵循審查過程中重新生成該產品嗎？同樣，該團隊能夠重新生成構建或發布環境（操作系統、庫，服務器內存配置，等等）嗎？
理想情況下，您想要剛好夠用的結構來直接處理像這樣的問題，但仍舊可以靈活地選擇在每個單個開發規程中使用最新和最好的的工具。這將是令開發團隊更快地交付軟件的一種方法，同時也令開發過程 —— 而且特別是構建過程 —— 更加可靠、一致，且可重復。
剛好夠用的結構
要知道構建管理系統中“剛好夠用的結構”的含義的一個方法是后退一步，確定優化構建和發布活動的質量和效率所需的跨規程的能力，不管每個規程是如何完成其特定的任務的。
將一個可伸縮的、有效的構建及發布管理基礎架構看作是現代的州際高速公路，將軟件開發規程看作是高速公路上的汽車。不論您開的是什么種類的車，跑車或小型貨車，高速公路都有效地工作，在這種意義上說，它讓您到達您需要去的地方。如果您擁有較快的車，那么您就更快地到達那里，但以哪種方式，基礎結構都支持您，并且它不規定您選擇駕駛哪種車。
同樣，不論您使用什么工具，您希望跨過程的結果是一致的。讓我們來看看，一個健壯、結構化的構建過程是如何幫助提供一致性的。
也許您從一個可伸縮的、跨規程的構建管理過程獲得關鍵能力是跨開發活動的更好的可見性。這是極其有價值的，因為當有東西失敗時，您可以更快速地看到發生了什么。舉例來說，如果一個構建總是在特定點失敗，那么您可以很容易地確定需要從哪個規程找原因了，因為您的過程是一致的，且定義良好的。那么您可以深入到問題出現的區域，并且快速地將其查出來。
缺少了適當的工具，這種水平的對問題自動的可視能力基本上是不可能的。相反，您需要召集一個有來自每個規程的代表參加的會議，試圖弄清誰是做什么的，然后從那里開始推斷對問題的解決方案...，退一步說，不是非常高效的。
您從一個可伸縮的、跨規程的構建管理過程獲得的另一個關鍵能力是構建產品過程中所涉及的團隊功能之間的溝通的改善�，F今，大多數構建過程中，存在相當多手工溝通。例如，當開發人員檢入代碼時，她也許需要發一個電子郵件給構建工程師或其他人來開始一個構建過程。如果構建工程師早些時候離開去看牙醫了，那么構建可能直到第二天早晨才能進行。這些種類的手工控制都減少了最終質量，并且增加了投放市場的時間。
手工構建過程中需要出現的所有各種各樣的溝通點 —— 與開發、源控制、構建、測試、打包和部署相關 —— 生成了許多會延遲發布的潛在的缺口和時間槽。并且隨著發布的推遲，將會削減特性，有時候削減測試 —— 為了滿足交付日期，什么事情都有可能發生，而許多都給項目增加了風險，并且消極地影響了質量。
溝通的進一個層面就是文檔。在自制的構建過程的情況下，每個規程中的團隊成員可能會手工地創建許多很快過期的文檔�？珥椖康�，自動的構建管理的優勢是它從頭到尾都跟蹤并控制所有的構建及發布活動，因此，可以讓這些活動自己文檔化。這也是將構建過程結構化如何減少整個團隊工作，不是增加，的另一個實例。
構建管理系統也應該可以通過自動化更加容易地指定并執行各種標準，為了讓過程更可預測，您需要將一些東西標準化，這樣過程中所涉及的所有功能區域就都知道它們了。
命名約定就是一個很好的實例。為了跨規程將活動自動化，您需要確保所涉及的領域（開發、配置管理、測試等等）遵守適當的命名標準，以便它們擁有公共的參考體系，用來跨特定領域確定并關聯構建的輸入和輸出。
標準可適用的另一個領域是過程的最佳實踐復用。從事于多個、復雜的項目（例如，SOA）的大型、分布的項目的開發組織從為構建管理規定特定最佳實踐活動的能力上獲得了驚人的收益。例如，您可能希望命令每個項目團隊都以與法規遵循或內部治理目的相關的報告形式獲得具體的構建或部署數據。當關鍵業務的活動自動化、文檔化，并可以復用時，團隊極可能遵循它們。與此同時，讓團隊復用最佳實踐，而不是重新將時間再次花在不同的項目上，這將幫助您減少項目的啟動時間，減少重復工作，并且增強效率和整個產品質量。
跨規程的安全性是良構的構建和發布管理過程的另一個優點。例如，特定的角色或人員可能得益于在開發生命周期的各種階段訪問正在構建的軟件的不同元素，讓我說，就是通過運行一些測試來檢查一些代碼的健全性。但他們可能不必要在那些階段擁有或控制那些元素（例如，測試腳本或無論什么）。
能夠以授權和控制的形式建立安全機制，超越每個功能的工具集，圍繞構建或部署過程中的整成點，可以有益于質量和效率。這是可以使開發人員在不需要于周日下午叫上構建工程師就可以安全地運行構建的東西。恰當的控制幫助消除了開發過程中殘余的大量廢物和閑散，并且實際地增加了靈活性。
像安全性一樣，狀態信息是超越任一個規程的軟件開發的另一個方面。當您正在為發布而工作時，對您來說，實時地確定項目狀態有多容易？您是處于測試階段還是打包階段？構建通過了所有測試嗎，只通過了一些測試，等等？當您不能自頂向下地觀察您的過程時，回答這種問題將是復雜，且耗費時間的。企業級構建管理系統可以幫助較大的團隊處理這種跨規程的問題。
量度是確定項目狀態能力的一個方面。當項目中的所有人都在同一個建筑物中工作時，狀態信息比較容易得到。但是當團隊在地理上分散時，溝通尤其不足。您需要以某種方式跨分布的過程測量關鍵的量度，從而確定狀態。
事實上，您真正需要的是從一個中央位置綜合地觀察所有的運作的開發活動，從那里您可以觀察，并度量您需要知道的任何事情。您是否花費過多的時間來開發或測試呢，如果是，為什么？當適當的結構連接規程時，做出這些種類的判定就容易得多了。
同理，當不從高層次觀察您的整個過程時，您真的不會一看就知道缺陷在哪里，更不用說如何解決了。有了適當的量度，您就可以分析隨著時間發展的過程趨勢，從而確定瓶頸，并且不斷地改進您的過程。缺少了量度，您就不得不利用所謂的“宗族的知識”、口述的意見、許多電子郵件，等等，手工地推斷出那些判斷。
重新定義敏捷開發
您會發現關于什么構成了“敏捷性”或“敏捷開發”的許多不同的看法 —— 但您找不到一個打算爭論更快地向市場交付更高質量產品的工具和過程的開發經理。
越來越多的組織開始通過更頻繁的代碼集成，部署提高質量并減少缺陷數量的敏捷類型的實踐。當開發人員更加頻繁地集成代碼時，它們會更快地發現問題，并且在向下傳之前修正它們。不幸的是，除了小型開發團隊，對于其余所有開發團隊來說，敏捷的好處大部分都沒用到，或者大部分受限于開發規程。開發團隊可能更頻繁地迭代，但缺少了包含適當結構和控制的自動支持，就不能同樣地促進構建活動，并且測試活動等也不能。
將構建管理自動化是將敏捷引入較大團隊的一種方法 —— 同時還擴展了它們的范圍和價值。實際上，企業級構建自動化能夠重新定義“敏捷”，因為它令敏捷驅動的效率收益，越過開發方法到構建、測試、打包，及部署方法。也就是說，雖然開發人員更頻繁地集成代碼，但是健壯的構建自動化令其他規程也同樣這樣做：更頻繁地構建、更頻繁地測試，等等。通過去除了構建或部署循環中的瓶頸，整個軟件開發生命周期可以更高效地進行。
當您在開發過程上使用恰當種類的跨功能的結構時，您可以使它更有效。假定您在美國的構建管理團隊，與印度的開發團隊合作，該團隊只是檢入一些源代碼。他們現在需要等待數小時，等您睡醒，然后構建嗎？如果是這樣，那就不是“敏捷”了。
當構建管理適當地自動化時，海外的團隊可以登錄您的構建系統，自己運行構建過程（不用您照顧著），獲得結果，了解到他們所檢入的代碼是否工作，及時地解決各種問題，等等。當您回到工作中來的時候，您的同事可能在您沒有發覺之前，已經經過了許多這樣的迭代。
這里有一個真實世界的實例：在 IBM Rational Build Forge 客戶的其中一個那里，一個非常大型且分布的開發組織從一周進行 18 次構建到每周進行 360 次構建，將較頻繁的代碼集成的質量和效率收益從開發人員傳遞到 QA 團隊（現在可以更頻繁地測試更多構建），并且跨整個軟件開發生命周期。如今這才是“敏捷”。
為了說明健壯的構建管理可以令開發人員 —— 以及整個團隊 —— 更高效的另一種方法，讓我們來想象另一個典型的軟件開發情景。開發人員在其本地的工作區中編碼并編譯。在某一時刻，每個開發人員都必須將他的或她的的代碼檢入到源控制系統中，以考察這些代碼是否能和其他人編寫并提交的代碼一起工作。常常，在本地工作區可以工作的代碼在構建時刻就出現失�。ɑ蛘咂茐钠渌a）—— 這是大多數項目每天延遲的原因。
團隊傾向于這樣工作的一部分原因是傳統上開發和配置管理之間有一堵墻，因為這些功能本質上重視不同的東西：分別是速度與過程控制。開發人員抵抗著對他們的工具和過程的約束，因此，不論是誰管理源代碼都需要讓開發人員與之保持安全距離。
相反，如果您可以安全地讓開發人員在構建管理的范圍內工作，而不需要在任何人的部分上對速度、靈活性，或過程控制進行妥協，該怎么辦？設想在不檢入代碼的情況下，您的開發人員是否可以通過在本地的工作區之外運行個人的“集成構建”來預檢查代碼。
考慮一下，如果開發人員可以從單元測試到進一步的測試，并且在正式的構建過程之外驗證其新的代碼，而不涉及其他開發人員的新代碼的話，那么有多少要出現的缺陷不會出現在構建中，并且因此能夠多通過多少次構建。想想開發人員會多頻繁且多有信心地檢入他們的代碼 —— 從而進一步提高了整個團隊的效率。
這些是對于自動構建管理帶到現實中的“開發人員自服務”和“連續集成”的構想的重要方面。這種更高層次的效率和控制使所有開發規程更頻繁地迭代，并且全面提高了生產力和質量。
IBM Rational Build Forge
IBM Rational Build Forge 提供了滿足大型開發團隊需求的自動的構建管理和軟件交付過程。Build Forge 減少了規程之間重要集成點處的手工活動，同時自動地獲取法規遵循、治理，或項目管理目的的相關數據。
Build Forge 提供的關鍵特性：
- 用于集中管理豎井式的構建或發布過程的基于 Web 的控制臺，以及簡化的用戶管理
- 自動地關聯來自不同源控制、測試，及缺陷跟蹤工具的數據，以在高層觀察產品開發狀態的能力
- 跨多個平臺與現有的工具靈活地集成，因此個別規程不受最佳解決方案選擇的約束
- 支持線程，因此，您可以將構建分成可以同時運行的獨立的過程，優化硬件利用和構建時間
- 為了更好地再現構建、更快地解決問題，簡化法規遵循管理，并提高測試準確度而自動編制材料單（一系列內容和變更）
- “最佳實踐過程”庫，您可以在項目間復用，從而減少啟動時間，提高可伸縮性，并增加效率和質量
- 隨著重要過程的演進，自動對其進行文檔編制 —— 為法規遵循管理提供過程變更的審計跟蹤，使工作量的共享和轉移更加容易，并且減少“人才流失”的風險，因為（晦澀難懂的）過程的詳細知識對構建的管理不是必要的
- 開放的命令行界面讓團隊可以在過程之間創建“智能鏈接”，從而優化效率，并改進故障排查
- 開發人員自服務能力，例如，開發人員可以在檢入代碼之前，通過在基于 Eclipse 的 IDE 中按照需求安全地運行構建來進行預測試（也就是說，讓代碼“試運行”）
Rational Build Forge 使團隊更快地、更頻繁地，并且具有更大信心地生成構建，因而促進了整個開發工作，并且支持質量管理計劃。
結束語
雖然許多軟件開發規程（源控制、缺陷跟蹤、測試等等）愿意進行成熟、健壯的自動化，但是企業團隊將構建和發布管理過程自動化的能力只是最近才出現的。同時，促進像 SOA 這樣的趨勢、增大法規遵從的風險，以及分布開發普遍性的增加，都對現今自制的構建或部署系統施加了巨大的壓力。
不能夠生成一致、準確，且可重復的軟件構建已經成為約束質量和效率的主要控制因素。特別地，豎井式的以規程為中心的構建過程使跨軟件生命周期的消息共享十分困難，并且導致不必要的錯誤、令人沮喪的延遲，以及成本和進度風險的增加。
軟件開發生命周期中的最佳實踐和過程改進已經成為 IBM Rational 的核心能力。我們在 Rational Build Forge 中提供的可伸縮的構建管理基礎架構可以擴展跨整個軟件開發生命周期的質量管理，與此同時，提高團隊效率和生產力。去除了手工協調控制，并且改進了對項目狀態的可視化的更加健壯的構建或發布過程意味著，花費更少的時間來從失敗中恢復，并且在錯誤影響構建并延遲測試之前，提前查明并解決錯誤上升趨勢的能力提高了。
隨著企業團隊獲得構建和發布自動化的經驗，例如，Build Forge 所提供的，它們可能希望進一步進行由壓縮了的開發進度，和利用來自構建系統的長期數據將活動流水化、改進計劃，并簡化法規遵循和內部治理的能力所推動的過程改進。組織還可以通過增強以及時的方式，在一致的基礎上提供高質量軟件的能力來加強它們的客戶關系。
所有這些過程改進都導致了軟件質量管理的能力的提高，產生了最佳的投資效率、最佳的時間與價值比，以及客戶滿意度的提高。對于許多中型到大型的開發團隊，或者分布團隊來說，問題不是您是否要實現可伸縮的構建管理自動化，而是什么時候實現它們。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
