你知道SQL Server這麼龐大的企業級數據庫服務器產品是如何build出來的嗎？
這有些相關的數據：
每個build 的大小在300GB左右。
每個完整的build需要幾十台高端的服務器運行2.5天。
每個完整的build由幾千個job、10000多個參數組成。
我們每天同時做20個左右的build，每周130個。
位於美國微軟總部雷蒙德和北京的build團隊能夠保證build全天24小時不間斷的順利進行。
從去年至今，我們build team已經成功而准時地完成了數以千計的build。
也許你會問：你們的build怎麼這麼大？怎麼需要這麼長的時間？為什麼你們每天要做這麼多build？
為什麼我們的一個build這麼大？比如說你的32位中文零售開發版SQL Server的DVD，包括工具和幫助 文檔是4GB，那麼你可以這樣估算一下：首先加上一些內部的build信息和統計，以及用於debug的Symbol ，然後乘以2（retail版，debug 版），再乘以3（CPU 類型：x86、x64和ia64），再乘以所有的版本數（ 企業版、開發版、標准版等），最後再乘以支持的語言數。不只1個TB 了吧？J 幸好SQL 2008 的setup 團隊采用了consolidated setup模式，這樣在一個語言包中，安裝程序可以判定你的CPU類型並根據你輸 入的產品序列號，自動安裝對應的版本。由此我們的build才壓縮到了300GB。
為什麼我們的一個build需要這麼長時間？Build這麼龐大的企業級數據庫服務器產品是一個極其復雜 的過程，況且SQL Server的build 系統已經是微軟內最為高效的系統之一。她是圖形化用戶界面並且高度 自動化的。歷經60小時，多數build會順利的自動完成並通知相關人員其build的狀態及信息。如果build 失敗，其也會提供詳細的錯誤信息用於debug。SQL Server的build 系統不僅如此易用和高效，同時可以 靈活的適應某些特殊的需求和build工作流。SQL Server的build 系統是由Windows Workflow Foundation 驅動的，其數以千計的job被並行或串行的分發到幾十台 build機器上並完成。build的過程包括：
將幾十GB的源文件及相關的所需文件和資源同步到build機器上
源代碼靜態分析
編譯所有的可執行文件和測試文件並簽名
生成系統數據庫
優化
本地化
制作安裝文件和安裝包並簽名
索引Symbol和源文件
我們每天做這麼多的build正體現了我們如何支持整個SQL Server工程體系和構架：
首先需要聲明的是我們隨時都在為多個產品提供支持，比如當前的SQL Server 2005和即將發布的SQL Server 2008。
在SQL Server 2008的工程體系和構架中，我們將每個需要增加或增強的功能特性做成一個單獨的分支 ，在這個功能特性開發和測試完成後，其代碼才會合並到SQL Server的主線代碼中。因此根據功能特性的 優先級和大小，SQL Server分成了幾十個不同的團隊，每個團隊包括了架構師、項目經理、開發和測試人 員，幫助及案例文檔專員，甚至科學家和科研人員。每個分支都需要build來進行及時的測試，因此有了 這個我們當前每周需要的build個數——130。當build結束後，Test Execution team和其分支 團隊會執行自動測試來確保其代碼的質量符合嚴格的要求和標准。最後當這個功能特性開發和測試完成後 ，其代碼將會融入到SQL Server的主線代碼中，然後其它各個分支團隊將重新獲取主線代碼並融合其分支 的當前代碼，來保證和主線代碼的同步。
那麼如何確保主線的代碼質量總是符合嚴格的要求和標准呢？我們將會在後續文章中揭示另一個神奇 的領域，下次見！
