评论数:28条

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

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

★管理问题


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


★人员问题


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


★硬件问题


  为了让整个流程能够走通,你得额外去申请一个发布服务器和若干个编译服务器(俺假定你公司已经有了单独的源代码服务器和 Bug 管理服务器)。
  发布服务器大体类似于一个共享文件服务器,将来每日自动生成的东东(一般是安装包或光盘镜像)就自动存放到上面。由于需要保存一段时间内每天构建的安装包(或安装光盘镜像),因此发布服务器对硬盘的要求比较高,其它配置倒无所谓。
  编译服务器主要是为了进行自动编译。假如你开发的是跨平台软件,可能会需要多个编译服务器(每种平台配一个);假如你开发的产品比较复杂,用一台机器编译太慢,可以考虑用多台机器并行做(听说微软对 Windows 搞每日构建就是多台服务器并行编译的,否则24小时都编译不完)。编译服务器对 CPU 和内存的要求会比较高,其它配置倒无所谓。


★软件问题


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


  上述就是几个方面的准备工作,下一个帖子咱们来聊一下具体的流程。
版权声明
本博客所有的原创文章,作者皆保留版权。转载必须包含本声明,保持本文完整,并以超链接形式注明作者编程随想和本文原始地址:
https://program-think.blogspot.com/2009/02/daily-build-2-prepare.html