如何编译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，当您可以这种估算一下：第1步加上多数内部的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工程体系和构架：

第1步就得声明的是大家随时总在为多个产品提供支持，打个比方当前的SQL Server 2005和就可以用公布的SQL Server 2008。

在SQL Server 2008的工程体系和构架中，大家用每个就得增加或增强的功能特性做成一个单独的分支，在这种功能特性设计和测试完成后，其代码才会合并到SQL Server的主线代码中。所以参考功能特性的优先级和大小，SQL Server分成了几十个不一样的团队，每个团队包括了架构师、项目经理、设计和测试人员，帮助及案例文档专员，甚至科学家和科研人员。每个分支总就得build来进行及时的测试，所以存在了这种大家当前每周就得的build个数——130。当build结束后，Test Execution team和其分支团队会执行自动测试来确保其代码的质量符合严格的需要和标准。最后当这种功能特性设计和测试完成后，其代码用会融入到SQL Server的主线代码中，接下来别的每个分支团队用重新获取主线代码并融合其分支的当前代码，来保证和主线代码的同步。

当如何确保主线的代码质量老是符合严格的需要和标准呢？大家用会在后续文章中揭示另一个神奇的领域，下回见！