每日构建不比其它纯技术的玩意儿，它是一个集体行为，它会改变包括“编程人员、测试人员、产品人员”等一堆人的工作模式。所以如果你想在公司里推广它，首先得掂量一下自己有几斤几两。一般来说，至少要做到项目主管或部门主管之类的级别，才有可能推得动。假设你尚未达到这种重量级，那看完本帖就算数，不可轻举妄动，切记、切记！
说到这里，有些涉世未深的同学可能有疑惑了，俺简单解释一下：假如你所在的公司非常地优秀、从谏如流、没有等级观念、易于接受新事物。且不说这样的公司在中国很少，即使你三生有幸正好待在这样的公司，公司里多半早就用上了每日构建，因此也轮不到你去操心了；反之，如果你的公司言路不畅、等级森严、抵触新事物，你在分量不够的情况下贸然跳出来，立马被一棍子打死。
好像有点跑题了，下面言归正传。本文会根据“管理、人员、硬件、软件”这4个维度，挨个介绍一下。
★管理问题
所谓管理问题，就是推行每日构建先要获得公司实权人物的撑腰，这点非常重要。根据俺以往的经验，要改变这么多人的工作习惯，必定会遭到极大的阻力、遭到各种质疑。一不小心就会被人家的口水给淹死。
那如何让公司的老大支持它捏？你可以把以前由于缺乏每日构建所导致的种种负面问题（这时候上一个帖子的几个案例就可以派上用场啦）向公司的老大哭诉（最好声泪俱下），要尽量让公司老大明白之前的种种问题已经对公司造成了重大的、不可估量的、无法弥补的损失......
如果你的运气好，老大一激动，就把这事给批了。然后你就可以拿着鸡毛当令箭，去干后面的事情了。
如果你的运气差：老大死活不表态支持你，那你只好暂时先放弃这一打算，后面几步也就不用搞了。
★人员问题
假设你搞定了管理问题，接下来就是着手解决人员问题。主要包括两方面：人员培训和指派一个构建责任人。
人员培训主要就是告诉相关的人员，将来每日构建的流程如何，各色人等该如何分工，各自承担什么责任，出了差错如何解决等等（具体的技术内容下一个帖子细说）。培训时要尽量让大伙儿理解这玩意儿的【切身】好处（比如可以减少扯皮）。
构建责任人（一般是兼任，不一定需要全职）主要承担和每日构建相关软硬件的维护工作，大体类似 IT 运维支持人员。另外，如果你公司对源代码非常敏感的话，这个“构建负责人”就得挑一个靠得住的人来担任。
★硬件问题
为了让整个流程能够走通，你得额外去申请一个发布服务器和若干个编译服务器（俺假定你公司已经有了单独的源代码服务器和 Bug 管理服务器）。
发布服务器大体类似于一个共享文件服务器，将来每日自动生成的东东（一般是安装包或光盘镜像）就自动存放到上面。由于需要保存一段时间内每天构建的安装包（或安装光盘镜像），因此发布服务器对硬盘的要求比较高，其它配置倒无所谓。
编译服务器主要是为了进行自动编译。假如你开发的是跨平台软件，可能会需要多个编译服务器（每种平台配一个）；假如你开发的产品比较复杂，用一台机器编译太慢，可以考虑用多台机器并行做（听说微软对 Windows 搞每日构建就是多台服务器并行编译的，否则24小时都编译不完）。编译服务器对 CPU 和内存的要求会比较高，其它配置倒无所谓。
★软件问题
到了这一步，基本上万事俱备了。然后就可以找个程序员来搞定和每日构建相关的各种【脚本】。主要有下面几种脚本：
1、从源代码服务器取出最新的源代码到编译服务器
2、在编译服务器上，把源代码编译为二进制文件，再把二进制文件制作成安装包
3、把安装包传到发布服务器
4、对安装包进行简单的冒烟测试（此脚本属于可选）
这些脚本相对都比较简单，基本上一个中等程度的程序员就能搞定。
上述就是几个方面的准备工作，下一个帖子咱们来聊一下具体的流程。
版权声明
本博客所有的原创文章，作者皆保留版权。转载必须包含本声明，保持本文完整，并以超链接形式注明作者编程随想和本文原始网址：https://program-think.blogspot.com/2009/02/daily-build-2-prepare.html