解密SQL Server資料庫系統的編譯

你知道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的主線代碼中，然後其它各個分支團隊將重新擷取主線代碼並融合其分支 的當前代碼，來保證和主線代碼的同步。

那麼如何確保主線的代碼品質總是符合嚴格的要求和標準呢？我們將會在後續文章中揭示另一個神奇 的領域，下次見！