你知道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的主线代码中，然后其它各个分支团队将重新获取主线代码并融合其分支的当前代码，来保证和主线代码的同步。

-- 转自SQL Server中国研发中心博客