你知道SQL Server這么龐大的企業(yè)級數(shù)據(jù)庫服務器產(chǎn)品是如何build出來的嗎?

這有些相關(guān)的數(shù)據(jù)：

每個build 的大小在300GB左右。

每個完整的build需要幾十臺高端的服務器運行2.5天。

每個完整的build由幾千個job、10000多個參數(shù)組成。

我們每天同時做20個左右的build，每周130個。

位于美國微軟總部雷蒙德和北京的build團隊能夠保證build全天24小時不間斷的順利進行。

從去年至今，我們build team已經(jīng)成功而準時地完成了數(shù)以千計的build。

也許你會問：你們的build怎么這么大?怎么需要這么長的時間?為什么你們每天要做這么多build?

為什么我們的一個build這么大?比如說你的32位中文零售開發(fā)版SQL Server的DVD，包括工具和幫助文檔是4GB，那么你可以這樣估算一下：首先加上一些內(nèi)部的build信息和統(tǒng)計，以及用于debug的Symbol，然后乘以2(retail版，debug 版)，再乘以3(CPU 類型：x86、x64和ia64)，再乘以所有的版本數(shù)(企業(yè)版、開發(fā)版、標準版等)，最后再乘以支持的語言數(shù)。不只1個TB 了吧?J 幸好SQL 2008 的setup 團隊采用了consolidated setup模式，這樣在一個語言包中，安裝程序可以判定你的CPU類型并根據(jù)你輸入的產(chǎn)品序列號，自動安裝對應的版本。由此我們的build才壓縮到了300GB。

為什么我們的一個build需要這么長時間?Build這么龐大的企業(yè)級數(shù)據(jù)庫服務器產(chǎn)品是一個極其復雜的過程，況且SQL Server的build 系統(tǒng)已經(jīng)是微軟內(nèi)最為高效的系統(tǒng)之一。她是圖形化用戶界面并且高度自動化的。歷經(jīng)60小時，多數(shù)build會順利的自動完成并通知相關(guān)人員其build的狀態(tài)及信息。如果build失敗，其也會提供詳細的錯誤信息用于debug。SQL Server的build 系統(tǒng)不僅如此易用和高效，同時可以靈活的適應某些特殊的需求和build工作流。SQL Server的build 系統(tǒng)是由Windows Workflow Foundation驅(qū)動的，其數(shù)以千計的job被并行或串行的分發(fā)到幾十臺 build機器上并完成。build的過程包括：

將幾十GB的源文件及相關(guān)的所需文件和資源同步到build機器上

源代碼靜態(tài)分析

編譯所有的可執(zhí)行文件和測試文件并簽名

生成系統(tǒng)數(shù)據(jù)庫

優(yōu)化

本地化

制作安裝文件和安裝包并簽名

索引Symbol和源文件

我們每天做這么多的build正體現(xiàn)了我們?nèi)绾沃С终麄€SQL Server工程體系和構(gòu)架：

首先需要聲明的是我們隨時都在為多個產(chǎn)品提供支持，比如當前的SQL Server 2005和即將發(fā)布的SQL Server 2008。

在SQL Server 2008的工程體系和構(gòu)架中，我們將每個需要增加或增強的功能特性做成一個單獨的分支，在這個功能特性開發(fā)和測試完成后，其代碼才會合并到SQL Server的主線代碼中。因此根據(jù)功能特性的優(yōu)先級和大小，SQL Server分成了幾十個不同的團隊，每個團隊包括了架構(gòu)師、項目經(jīng)理、開發(fā)和測試人員，幫助及案例文檔專員，甚至科學家和科研人員。每個分支都需要build來進行及時的測試，因此有了這個我們當前每周需要的build個數(shù)——130。當build結(jié)束后，Test Execution team和其分支團隊會執(zhí)行自動測試來確保其代碼的質(zhì)量符合嚴格的要求和標準。最后當這個功能特性開發(fā)和測試完成后，其代碼將會融入到SQL Server的主線代碼中，然后其它各個分支團隊將重新獲取主線代碼并融合其分支的當前代碼，來保證和主線代碼的同步。