你知道SQL Server这么庞大的企业级数据库服务器产品是如何build出来的吗？
这有些相关的数据
每个build 的大小在GB左右
每个完整的build需要几十台高端的服务器运行天
每个完整的build由几千个job多个参数组成
我们每天同时做个左右的build每周个
位于美国微软总部雷蒙德和北京的build团队能够保证build全天小时不间断的顺利进行
从去年至今我们build team已经成功而准时地完成了数以千计的build
也许你会问你们的build怎么这么大？怎么需要这么长的时间？为什么你们每天要做这么多build？
为什么我们的一个build这么大？比如说你的位中文零售开发版SQL Server的DVD包括工具和帮助文档是GB那么你可以这样估算一下首先加上一些内部的build信息和统计以及用于debug的Symbol然后乘以（retail版debug 版）再乘以（CPU 类型xx和ia）再乘以所有的版本数（企业版开发版标准版等）最后再乘以支持的语言数不只个TB 了吧？J 幸好SQL 的setup 团队采用了consolidated setup模式这样在一个语言包中安装程序可以判定你的CPU类型并根据你输入的产品序列号自动安装对应的版本由此我们的build才压缩到了GB
为什么我们的一个build需要这么长时间？Build这么庞大的企业级数据库服务器产品是一个极其复杂的过程况且SQL Server的build 系统已经是微软内最为高效的系统之一她是图形化用户界面并且高度自动化的历经小时多数build会顺利的自动完成并通知相关人员其build的状态及信息如果build失败其也会提供详细的错误信息用于debugSQL Server的build 系统不仅如此易用和高效同时可以灵活的适应某些特殊的需求和build工作流SQL Server的build 系统是由Windows Workflow Foundation驱动的其数以千计的job被并行或串行的分发到几十台 build机器上并完成build的过程包括
将几十GB的源文件及相关的所需文件和资源同步到build机器上
源代码静态分析
编译所有的可执行文件和测试文件并签名
生成系统数据库
优化
本地化
制作安装文件和安装包并签名
索引Symbol和源文件
我们每天做这么多的build正体现了我们如何支持整个SQL Server工程体系和构架
首先需要声明的是我们随时都在为多个产品提供支持比如当前的SQL Server 和即将发布的SQL Server
在SQL Server 的工程体系和构架中我们将每个需要增加或增强的功能特性做成一个单独的分支在这个功能特性开发和测试完成后其代码才会合并到SQL Server的主线代码中因此根据功能特性的优先级和大小SQL Server分成了几十个不同的团队每个团队包括了架构师项目经理开发和测试人员帮助及案例文档专员甚至科学家和科研人员每个分支都需要build来进行及时的测试因此有了这个我们当前每周需要的build个数——当build结束后Test Execution team和其分支团队会执行自动测试来确保其代码的质量符合严格的要求和标准最后当这个功能特性开发和测试完成后其代码将会融入到SQL Server的主线代码中然后其它各个分支团队将重新获取主线代码并融合其分支的当前代码来保证和主线代码的同步
那么如何确保主线的代码质量总是符合严格的要求和标准呢？我们将会在后续文章中揭示另一个神奇的领域下次见！
