软件工程进阶之每日构建[2]：准备工作

　　上一个帖子务虚了一下每日构建的几个主要好处。今天开始来说点实在的：也就是每日构建具体要如何开始搞，要做哪些准备工作（如果你所在的团队已经在用每日构建，你可以跳过这个帖子）。<!--program-think-->

　　每日构建不比其它纯技术的玩意儿，它是一个集体行为，它会改变包括编程人员、测试人员、产品人员等一堆人的工作模式。所以如果你想在公司里推广它，首先 得掂量一下自己有几斤几两。一般来说，至少要做到项目主管或部门主管之类的级别，才有可能推得动。假设你尚未达到这种重量级，那看完本帖就算数，不可轻举 妄动，切记、切记。
　　说到这里，有些涉世未深的同学可能有疑惑了，我简单解释一下：假如你所在的公司非常地优秀、从谏如流、没有等级观念、易于 接受新事物。且不说这样的公司在中国很少，即使你三生有幸正好待在这样的公司，公司里多半早就用上了每日构建，因此也轮不到你去操心了；反之，如果你的公 司言路不畅、等级森严、抵触新事物，你在分量不够的情况下贸然跳出来，立马被一棍子打死。
　　有点跑题了，下面言归正传，根据管理、人员、硬件、软件这4个方面，挨个介绍一下。

　　★管理问题
　　所谓管理问题，就是推行每日构建先要获得公司实权人物的撑腰，这点非常重要。根据我以往的经验，要改变这么多人的工作习惯，必定会遭到极大的阻力、遭到各种质疑。一不小心就会被人家的口水给淹死。
　　那如何让公司的老大支持它捏？你可以把以前由于缺乏每日构建所导致的种种负面问题（这时候上一个帖子的几个案例就可以派上用场啦）向公司的老大哭诉（最好声泪俱下），要尽量让公司老大明白之前的种种问题已经对公司造成了重大的、不可估量的、无法弥补的损失......
　　如果你的运气好，老大一激动，就把这事给批了。然后你就可以拿着鸡毛当令箭，去干后面的事情了。
　　如果你的运气差：老大死活不表态支持你，那你只好暂时先放弃这一打算，后面几步也就不用搞了。

　　★人员问题
　　假设你搞定了管理问题，接下来就是着手解决人员问题。主要包括两方面：人员培训和指派一个构建责任人。
　　人员培训主要就是告诉相关的人员，将来每日构建的流程如何，各色人等该如何分工，各自承担什么责任，出了差错如何解决等等（具体的技术内容下一个帖子细说）。培训时要尽量让大伙儿理解这玩意儿的切身好处（比如可以减少扯皮）。
　　构建责任人（一般是兼任，不一定需要全职）主要承担和每日构建相关软硬件的维护工作，大体类似IT运维支持人员。另外，如果你公司对源代码非常敏感的话，这个“构建负责人”就得挑一个靠得住的人来担任。

　　★硬件问题
　　为了让整个流程能够走通，你得额外去申请一个发布服务器和若干个编译服务器（我假定你公司已经有了单独的源代码服务器和Bug管理服务器）。
　　发布服务器大体类似于一个共享文件服务器，将来每日自动生成的东东（一般是安装包或光盘镜像）就自动存放到上面。发布服务器对硬盘的要求比较高（我负责的这个产品，每天生成3个ISO共两百多兆），其它配置倒无所谓。
　 　编译服务器主要是为了进行自动编译。假如你开发的是跨平台软件，可能会需要多个编译服务器（每种平台配一个）；假如你开发的产品比较复杂，用一台机器编 译太慢，可以考虑用多台机器并行做（听说Windows的每日构建就是多台服务器并行编译的）。编译服务器对CPU和内存的要求会比较高，其它配置倒无所 谓。

　　★软件问题
　　到了这一步，基本上万事俱备了。然后就可以找个程序员来搞定和每日构建相关的各种脚本。主要有下面几种脚本：
　　1、从源代码服务器取出最新的源代码到编译服务器
　　2、在编译服务器上，把源代码编译为二进制文件，再把二进制文件制作成安装包
　　3、把安装包传到发布服务器
　　4、对安装包进行简单的冒烟测试（此脚本属于可选）
　　这些脚本相对都比较简单，基本上一个中等程度的程序员就能搞定。

　　上述就是几个方面的准备工作，下一个帖子我们来聊一下具体的流程。

http://program-think.blogspot.com/2009/02/daily-build-2-prepare.html