“每日构建”的好处 by 编程随想
pongba
请大家订阅吧，我就不继续转载了 :)
------------------
在昨天"正确地做事(善用工具)"的帖子里提到了代码提交的频度问题。当时我特别强调了"要保证提交的代码能编译通过"， 理由是"对于每日构建很重要"。我估计列位看官中，不太熟悉每日构建的，大有人在；而且国内停留在手工作坊阶段的软件公司，为数也不少。因此今天我们就来 说一下"每日构建"这个话题。假如你平时已经很善于运用"每日构建"这一有效的手段，可以直接略过本系列，去看其它帖子。
照例先来说说什么是"每日构建"，每日构建在洋文里也称为Daily Build或者Nightly Build。具体定义见"这里"。简单地讲，就是每天都把整个软件项目自动编译一遍，最终生成的产出物必须和交付到用户手中的一样（比如你最终提交给用户的是一个安装程序，那就必须在开发过程中每天编译出一个安装包）。
为了表明每日构建是一个很有效的手段，我可以给大伙举几个知名软件公司或者著名开源项目的例子：
1、微软公司内部几乎所有产品的开发过程，都会使用每日构建。
2、我不确定Google是否所有产品都采用，但至少Google的Chrome浏览器是采用每日构建。
3、知名的开源组织Mozilla也大量使用每日构建。
4、知名的Linux发行版Ubuntu也使用每日构建。
......
上面这个列表还可以罗列很长。举这么多例子，无非想说，每日构建是一种牛X的软件工程手段。尤其对于复杂项目和大型团队，它的好处更加明显。看到这儿，有同学可能要问了，具体有些什么好处捏？请看"软件工程进阶之每日构建[1]：好处和优点"。
上一个帖子提到说每日构建是一种很牛X的软件工程手段。本帖子就来说说它到底有多牛X。为了加深大伙儿的印象，我先来说一些陈年往事。
话说上世纪末，我还在一家小公司干活，并参与开发了一个C++的项目。当时公司的流程是：开发人员写好代码，自己编译好，丢给测试人员测试；测试人员如果发现bug，口头通知开发人员改；开发人员改好bug，再丢给测试人员测试......
●案例1（开发的混乱）
有一天，开发组的小头目找来程序员甲。
>>小头目：你负责的XX功能完成了没有？
>>程序员甲：早做完啦！
>>小头目：那测试人员甲怎么说一直没看到XX功能？
>>程序员甲：不会吧！我去瞧瞧。
若干分钟后，程序员甲回来。
>>程序员甲：不好意思，编译好的EXE我只发给了测试人员乙，忘记发给测试人员甲了。
>>小头目：!@#$%^&*（此处省略15字）
●案例2（测试的混乱）
另一天刚上班。
>>测试人员甲：今天的XX.EXE怎么一运行就崩溃？
>>测试人员乙：有吗？我这儿好好的呀！
>>测试人员甲：真见鬼！我找开发问一下。
经过若干分钟打听，知道XX.EXE是程序员丙负责，于是找来程序员丙。
>>测试人员甲：为啥你做的XX.EXE一运行就崩溃？
>>程序员丙：有这回事？！让我看看你的环境。
程序员丙在测试人员甲的机器上研究了N刻钟后。
>>程序员丙：你是猪脑啊，你没有更新XXX.DLL，害我浪费这么长时间！
>>测试人员甲：你才是猪脑！我怎么知道XX.EXE会用到XXX.DLL？
然后两人开始对骂......
●案例3（集成的混乱）
临近项目交付了，开发人员都在忙着改bug，测试人员都在忙着复测bug，没有人手准备安装包，于是安装包的制作一直拖到项目交付的前一天才开始搞。制作安装包本身倒是很快，半天就搞定。但是......
>>小头目：做好的安装包应该没什么问题吧？
>>测试人员丙：呃，这个，这个......好像装出来的软件没法运行，直接崩溃了。
>>小头目：偶的神啊！还愣着干嘛，快去查原因！！！今天不搞定大家不许回家！！！
然后开发和测试通力协作，经过艰苦卓绝的努力，到了午夜时分，终于发现：有个DLL是Debug版本......
有同学可能会问：为啥平时测试的时候没发现这个问题捏？因为平时团队里面都使用Debug版本，方便ASSERT断言。到了作安装包那天，照道理应该统 一编译Release版本，但是有个家伙遗漏了，所以混了一个Debug版本的DLL在里面。等安装完运行程序时，该DLL动态加载失败，所以程序就崩溃 鸟。
我上面说的这些情形，到今天为止，还在很多公司内部上演。那为啥每日构建能搞定上面这些问题捏？且听我细细道来：
●针对"开发的混乱"
对于每日构建的流程，开发人员只要负责提交代码到代码库中。不需要挨个给测试人员提供编译后的二进制文件。因此案例1的问题（漏给测试文件）迎刃而解。
●针对"测试的混乱"
在开发阶段，由于测试拿到的程序都是自动编译出来的，因此保证了所有测试人员拿到的是统一的运行程序，并且这个程序和代码库中最新的代码是相对应的。
在测试阶段，每一个开发人员修复了Bug之后，都必须把改过的代码提交到代码库，测试人员才会拿到改过Bug的二进制程序。如果某个开发人员改了Bug但是不提交代码，那么在测试人员看来，相当于他的Bug一直没有改，因此他的Bug就一直不会被关闭。
所以案例2的情况也不会出现。
●针对"集成的混乱"
对于每日构建来说，每天都会产生安装包（或者安装光盘的ISO镜像）。也就是说，从项目开始开发的那天起，每天都在进行集成（这就是传说中的持续集成）。因此，集成的问题，在一开始就会暴露出来，而不用等到项目后期。
其实每日构建的好处除了上述三点（这三点我认为比较重要），还有其它很多，大伙儿可以自己再琢磨一下。后面一个帖子，我把每日构建的流程详细介绍一下。
--
刘未鹏(pongba)
Blog | Mind Hacks
http://mindhacks.cn
TopLanguage
http://groups.google.com/group/pongba
missdeer
On Feb 16, 6:15 pm, pongba <pon...@gmail.com> wrote:
> 来自：http://program-think.blogspot.com/
> 请大家订阅吧，我就不继续转载了 :)
>
> ------------------
>
> 在昨天"正确地做事(善用工具) <http://program-think.blogspot.com/2009/02/6.html>
> "的帖子里提到了代码提交的频度问题。当时我特别强调了"*要保证提交的代码能编译通过*"，
> 理由是"对于每日构建很重要"。我估计列位看官中，不太熟悉每日构建的，大有人在；而且国内停留在手工作坊阶段的软件公司，为数也不少。因此今天我们就来
> 说一下"每日构建"这个话题。假如你平时已经很善于运用"每日构建"这一有效的手段，可以直接略过本系列，去看其它帖子。
> 照例先来说说什么是"每日构建"，每日构建在洋文里也称为Daily Build或者Nightly
> Build。具体定义见"这里<http://en.wikipedia.org/wiki/Daily_build>
> "。简单地讲，就是每天都把*整个*软件项目*自动*
> 编译一遍，最终生成的产出物必须和交付到用户手中的一样（比如你最终提交给用户的是一个安装程序，那就必须在开发过程中每天编译出一个安装包）。
> 为了表明每日构建是一个很有效的手段，我可以给大伙举几个知名软件公司或者著名开源项目的例子：
> 1、微软公司内部几乎所有产品的开发过程，都会使用每日构建。
> 2、我不确定Google是否所有产品都采用，但至少Google的Chrome浏览器是采用每日构建。
> 3、知名的开源组织Mozilla也大量使用每日构建。
> 4、知名的Linux发行版Ubuntu也使用每日构建。
> ......
> 上面这个列表还可以罗列很长。举这么多例子，无非想说，每日构建是一种牛X的软件工程手段。尤其对于复杂项目和大型团队，它的好处更加明显。看到这儿，有同学可 能要问了，具体有些什么好处捏？请看"
> 软件工程进阶之每日构建[1]：好处和优点<http://program-think.blogspot.com/2009/02/daily-build-1-advantage.html>
> "。
>
> 上一个帖子<http://program-think.blogspot.com/2009/02/daily-build-0-overview.html>
> 提到说每日构建是一种很牛X的软件工程手段。本帖子就来说说它到底有多牛X。为了加深大伙儿的印象，我先来说一些陈年往事。
> 话说上世纪末，我还在一家小公司干活，并参与开发了一个C++的项目。当时公司的流程是：开发人员写好代码，自己编译好，丢给测试人员测试；测试人员如果发现b ug，口头通知开发人员改；开发人员改好bug，再丢给测试人员测试......
>
> ●案例1（开发的混乱）
> 有一天，开发组的小头目找来程序员甲。>>小头目：你负责的XX功能完成了没有？
> >>程序员甲：早做完啦！
> >>小头目：那测试人员甲怎么说一直没看到XX功能？
> >>程序员甲：不会吧！我去瞧瞧。
>
> 若干分钟后，程序员甲回来。
>
> >>程序员甲：不好意思，编译好的EXE我只发给了测试人员乙，忘记发给测试人员甲了。
> >>小头目：!@#$%^&*（此处省略15字）
>
> ●案例2（测试的混乱）
> 另一天刚上班。>>测试人员甲：今天的XX.EXE怎么一运行就崩溃？
> >>测试人员乙：有吗？我这儿好好的呀！
> >>测试人员甲：真见鬼！我找开发问一下。
>
> 经过若干分钟打听，知道XX.EXE是程序员丙负责，于是找来程序员丙。>>测试人员甲：为啥你做的XX.EXE一运行就崩溃？
> >>程序员丙：有这回事？！让我看看你的环境。
>
> 程序员丙在测试人员甲的机器上研究了N刻钟后。>>程序员丙：你是猪脑啊，你没有更新XXX.DLL，害我浪费这么长时间！
> >>测试人员甲：你才是猪脑！我怎么知道XX.EXE会用到XXX.DLL？
>
> 然后两人开始对骂......
>
> ●案例3（集成的混乱）
> 临近项目交付了，开发人员都在忙着改bug，测试人员都在忙着复测bug，没有人手准备安装包，于是安装包的制作一直拖到项目交付的前一天才开始搞。制作安装包 本身倒是很快，半天就搞定。但是......>>小头目：做好的安装包应该没什么问题吧？
> >>测试人员丙：呃，这个，这个......好像装出来的软件没法运行，直接崩溃了。
> >>小头目：偶的神啊！还愣着干嘛，快去查原因！！！今天不搞定大家不许回家！！！
>
> 然后开发和测试通力协作，经过艰苦卓绝的努力，到了午夜时分，终于发现：有个DLL是Debug版本......
> 有同学可能会问：为啥平时测试的时候没发现这个问题捏？因为平时团队里面都使用Debug版本，方便ASSERT断言。到了作安装包那天，照道理应该统
> 一编译Release版本，但是有个家伙遗漏了，所以混了一个Debug版本的DLL在里面。等安装完运行程序时，该DLL动态加载失败，所以程序就崩溃 鸟。
>
> 我上面说的这些情形，到今天为止，还在很多公司内部上演。那为啥每日构建能搞定上面这些问题捏？且听我细细道来：
>
> ●针对"开发的混乱"
> 对于每日构建的流程，开发人员只要负责提交代码到代码库中。不需要挨个给测试人员提供编译后的二进制文件。因此案例1的问题（漏给测试文件）迎刃而解。
>
> ●针对"测试的混乱"
> 在开发阶段，由于测试拿到的程序都是自动编译出来的，因此保证了所有测试人员拿到的是统一的运行程序，并且这个程序和代码库中最新的代码是相对应的。
> 在测试阶段，每一个开发人员修复了Bug之后，都必须把改过的代码提交到代码库，测试人员才会拿到改过Bug的二进制程序。如果某个开发人员改了Bug但是不提 交代码，那么在测试人员看来，相当于他的Bug一直没有改，因此他的Bug就一直不会被关闭。
> 所以案例2的情况也不会出现。
>
> ●针对"集成的混乱"
> 对于每日构建来说，每天都会产生安装包（或者安装光盘的ISO镜像）。也就是说，从项目开始开发的那天起，每天都在进行集成（这就是传说中的*持续集成*
xwssole
missdeer
做比较合适呢？我们开始的做法是开发团队中随便找个人来维护这个，目前公司意识到这个的重要性，就让配置管理员来做。感觉都不太好，但不好在哪里，又说
不出来，晕！
On Feb 16, 6:15 pm, pongba <pon...@gmail.com> wrote:
> 来自：http://program-think.blogspot.com/
> 请大家订阅吧，我就不继续转载了 :)
>
> ------------------
>
> 在昨天"正确地做事(善用工具) <http://program-think.blogspot.com/2009/02/6.html>
> "的帖子里提到了代码提交的频度问题。当时我特别强调了"*要保证提交的代码能编译通过*"，
> 理由是"对于每日构建很重要"。我估计列位看官中，不太熟悉每日构建的，大有人在；而且国内停留在手工作坊阶段的软件公司，为数也不少。因此今天我们就来
> 说一下"每日构建"这个话题。假如你平时已经很善于运用"每日构建"这一有效的手段，可以直接略过本系列，去看其它帖子。
> 照例先来说说什么是"每日构建"，每日构建在洋文里也称为Daily Build或者Nightly
> Build。具体定义见"这里<http://en.wikipedia.org/wiki/Daily_build>
> "。简单地讲，就是每天都把*整个*软件项目*自动*
> 编译一遍，最终生成的产出物必须和交付到用户手中的一样（比如你最终提交给用户的是一个安装程序，那就必须在开发过程中每天编译出一个安装包）。
> 为了表明每日构建是一个很有效的手段，我可以给大伙举几个知名软件公司或者著名开源项目的例子：
> 1、微软公司内部几乎所有产品的开发过程，都会使用每日构建。
> 2、我不确定Google是否所有产品都采用，但至少Google的Chrome浏览器是采用每日构建。
> 3、知名的开源组织Mozilla也大量使用每日构建。
> 4、知名的Linux发行版Ubuntu也使用每日构建。
> ......
> 上面这个列表还可以罗列很长。举这么多例子，无非想说，每日构建是一种牛X的软件工程手段。尤其对于复杂项目和大型团队，它的好处更加明显。看到这儿，有同学可 能要问了，具体有些什么好处捏？请看"
> 软件工程进阶之每日构建[1]：好处和优点<http://program-think.blogspot.com/2009/02/daily-build-1-advantage.html>
> "。
>
> 上一个帖子<http://program-think.blogspot.com/2009/02/daily-build-0-overview.html>
> 提到说每日构建是一种很牛X的软件工程手段。本帖子就来说说它到底有多牛X。为了加深大伙儿的印象，我先来说一些陈年往事。
> 话说上世纪末，我还在一家小公司干活，并参与开发了一个C++的项目。当时公司的流程是：开发人员写好代码，自己编译好，丢给测试人员测试；测试人员如果发现b ug，口头通知开发人员改；开发人员改好bug，再丢给测试人员测试......
>
> ●案例1（开发的混乱）
> 有一天，开发组的小头目找来程序员甲。>>小头目：你负责的XX功能完成了没有？
> >>程序员甲：早做完啦！
> >>小头目：那测试人员甲怎么说一直没看到XX功能？
> >>程序员甲：不会吧！我去瞧瞧。
>
> 若干分钟后，程序员甲回来。
>
> >>程序员甲：不好意思，编译好的EXE我只发给了测试人员乙，忘记发给测试人员甲了。
> >>小头目：!@#$%^&*（此处省略15字）
>
> ●案例2（测试的混乱）
> 另一天刚上班。>>测试人员甲：今天的XX.EXE怎么一运行就崩溃？
> >>测试人员乙：有吗？我这儿好好的呀！
> >>测试人员甲：真见鬼！我找开发问一下。
>
> 经过若干分钟打听，知道XX.EXE是程序员丙负责，于是找来程序员丙。>>测试人员甲：为啥你做的XX.EXE一运行就崩溃？
> >>程序员丙：有这回事？！让我看看你的环境。
>
> 程序员丙在测试人员甲的机器上研究了N刻钟后。>>程序员丙：你是猪脑啊，你没有更新XXX.DLL，害我浪费这么长时间！
> >>测试人员甲：你才是猪脑！我怎么知道XX.EXE会用到XXX.DLL？
>
> 然后两人开始对骂......
>
> ●案例3（集成的混乱）
> 临近项目交付了，开发人员都在忙着改bug，测试人员都在忙着复测bug，没有人手准备安装包，于是安装包的制作一直拖到项目交付的前一天才开始搞。制作安装包 本身倒是很快，半天就搞定。但是......>>小头目：做好的安装包应该没什么问题吧？
> >>测试人员丙：呃，这个，这个......好像装出来的软件没法运行，直接崩溃了。
> >>小头目：偶的神啊！还愣着干嘛，快去查原因！！！今天不搞定大家不许回家！！！
>
> 然后开发和测试通力协作，经过艰苦卓绝的努力，到了午夜时分，终于发现：有个DLL是Debug版本......
> 有同学可能会问：为啥平时测试的时候没发现这个问题捏？因为平时团队里面都使用Debug版本，方便ASSERT断言。到了作安装包那天，照道理应该统
> 一编译Release版本，但是有个家伙遗漏了，所以混了一个Debug版本的DLL在里面。等安装完运行程序时，该DLL动态加载失败，所以程序就崩溃 鸟。
>
> 我上面说的这些情形，到今天为止，还在很多公司内部上演。那为啥每日构建能搞定上面这些问题捏？且听我细细道来：
>
> ●针对"开发的混乱"
> 对于每日构建的流程，开发人员只要负责提交代码到代码库中。不需要挨个给测试人员提供编译后的二进制文件。因此案例1的问题（漏给测试文件）迎刃而解。
>
> ●针对"测试的混乱"
> 在开发阶段，由于测试拿到的程序都是自动编译出来的，因此保证了所有测试人员拿到的是统一的运行程序，并且这个程序和代码库中最新的代码是相对应的。
> 在测试阶段，每一个开发人员修复了Bug之后，都必须把改过的代码提交到代码库，测试人员才会拿到改过Bug的二进制程序。如果某个开发人员改了Bug但是不提 交代码，那么在测试人员看来，相当于他的Bug一直没有改，因此他的Bug就一直不会被关闭。
> 所以案例2的情况也不会出现。
>
> ●针对"集成的混乱"
> 对于每日构建来说，每天都会产生安装包（或者安装光盘的ISO镜像）。也就是说，从项目开始开发的那天起，每天都在进行集成（这就是传说中的*持续集成*
Stanley Xu
Best wishes,
Stanley Xu
http://www.xuwenhao.com
avalon
对上百人团队,代码文件在数千之上的项目,从daily build得到的好处,自然是远大
于构建
build及auto test系统的代价。tipcode要每天能保障正确被编译，这是让整个团
队继续
工作的基础，至于测试，除去能够auto test的部分，QA部门不太可能每天都能把
整个系统
测试一边，也不太可能每天都用tipcode编译出来的东西进行测试，实际的情况
是，一个复杂
的大型项目启动起来的相当长时间内，开发人员每天不断的checkin代码，这些
code根本不能运行...
到了一定阶段，开始有了雏形，然后开发部门开始release版本交给qa，qa经过一
段时间测试后反馈，
开发人员bugfix，然后过了一段时间再release一个版本，如此反复...相同的bug
反复被提交出来
是常有的事情。
但对于小公司，个人觉得，并没有太大意义。
Stanley Xu 写道:
> 很简单，你陷入了工具论的泥潭，工具当然有作用，可以改善开发流程和效率，
> 但是还是有人这个因素在那里。职责不明确的问题，是通过文化和沟通来解决
> 的，比如（1）谁先看到了build break就发信给大家说自己去着手解决 （2）谁
> 最后的commit break了build谁来解决 （3）project owner指定某人来解决
> （4）轮流维护，保证每个人都会搭CI，玩CI，也知道项目的每个部分
>
> Best wishes,
> Stanley Xu
> http://www.xuwenhao.com
>
>
> 2009/2/16 missdeer <miss...@gmail.com <mailto:miss...@gmail.com>>
>
> 在公司里用了一年多持续集成，这里讲的3个案例都有过亲身经历，有了CI
> 确实可以改善这方面的工作，不过有时候在团队中职责却不好明确，这工作
> 该让谁来
> 做比较合适呢？我们开始的做法是开发团队中随便找个人来维护这个，目前
> 公司意识到这个的重要性，就让配置管理员来做。感觉都不太好，但不好在
> 哪里，又说
> 不出来，晕！
>
> On Feb 16, 6:15 pm, pongba <pon...@gmail.com
> DLL在里面。等安装完运行程序时，该DLL动态加载失败，所以程序就崩溃鸟。
> >
> > 我上面说的这些情形，到今天为止，还在很多公司内部上演。那为啥每日
> 构建能搞定上面这些问题捏？且听我细细道来：
> >
> > ●针对"开发的混乱"
> > 对于每日构建的流程，开发人员只要负责提交代码到代码库中。不需要挨
> 个给测试人员提供编译后的二进制文件。因此案例1的问题（漏给测试文
> 件）迎刃而解。
> >
> > ●针对"测试的混乱"
> > 在开发阶段，由于测试拿到的程序都是自动编译出来的，因此保证了所有
> 测试人员拿到的是统一的运行程序，并且这个程序和代码库中最新的代码是
> 相对应的。
> > 在测试阶段，每一个开发人员修复了Bug之后，都必须把改过的代码提交
> 到代码库，测试人员才会拿到改过Bug的二进制程序。如果某个开发人员改
> 了Bug但是不提 交代码，那么在测试人员看来，相当于他的Bug一直没有
> 改，因此他的Bug就一直不会被关闭。
> > 所以案例2的情况也不会出现。
> >
> > ●针对"集成的混乱"
> > 对于每日构建来说，每天都会产生安装包（或者安装光盘的ISO镜像）。
> 也就是说，从项目开始开发的那天起，每天都在进行集成（这就是传说中的
> *持续集成*
> > ）。因此，集成的问题，在一开始就会暴露出来，而不用等到项目后期。
> >
> > 其实每日构建的好处除了上述三点（这三点我认为比较重要），还有其它
> 很多，大伙儿可以自己再琢磨一下。后面一个帖子，我把每日构建的流程详
> 细介绍一下。
> >
> > --
> > 刘未鹏(pongba)
> > Blog | Mind Hackshttp://mindhacks.cn <http://mindhacks.cn>
> > TopLanguagehttp://groups.google.com/group/pongba
> <http://groups.google.com/group/pongba>
>
>
莫华枫
元旦前，我们一个项目部署到用户那里。用了几天，总有毛病。一哥们儿天天去客户那里，天天让人骂回来。回来就嚷嚷，什么什么问题，什么什么不行了，就差痛哭流涕了。可家里头什么都好。不行了，时间也不够了，就加班吧。结果一伙人元旦放假三天，加了两天班。抓了几个小bug，建了测试机，没出现过的问题都找到了，可始终没有找出用户那些问题的原因。过了节一上班，项目里的几个主要人物一块儿去了用户那里，一回来就对骂。原来跑客户那哥们儿拿着一个很老的版本给客户装，数据结构和手持设备都不一样，怎么能不出问题呢。
--
反者道之动，弱者道之用
m...@seaskysh.com
longsh...@gmail.com
http://blog.csdn.net/longshanks/
Kenny Yuan
开发团队大到一定程度，管理上就出现许多"不可能"，于是问题就接二连三地出现了……坚持每日构建能改善一些问题，and that's it -- no silver bullet, no "十全大补丸"
P.S. 这东西在最初接触的时候，的确是很有震撼力的。我还能记得大约8年前，听人给我讲这个，把我讲得口水流到饭桌上的情景 :P
--
Kenny Yuan
C++, UI, LISP, MMA, Psychology and Automobile.
BLOG: CS巴别塔(Computer Science Babel)
URL: http://blog.csdn.net/yuankaining/
Stanley Xu
对于小公司怎么会没有意义呢，第一，在这个年代，假设daily build或者CI的代价非常之低，基本上在1man/day以下。第二，daily build或者CI能够保证trunk上的版本始终是可用的版本，随时可以发布。第三，保证了团队之间不慎commit入错误的代码、不完整的代码可以及早发现。
不能运行的代码根本就不应该checkin到trunk上，不能运行的代码或者说不完整的function不能称之为完成了工作，对公司和客户体现不出价值。
相同的bug被反复提交是典型的开发中的浪费，完全应该靠automate test来解决。
No Silver Bullet不是给你自己找借口去回避一些基本的best practice的。
我现在一个人写自己的代码都是Nightly Build给自己test result的。
看了两位的想法，我终于理解为什么现在还要整天宣传daily build这种基本的最佳实践了。
Zoom.Quiet
关键是可以过滤比较没有味道的Blog,
进步的可以在列表中进行深入的讨论，比分散的各自去Blog 注释要有效率的多，，，
--
http://zoomquiet.org
'''过程改进乃是催生可促生靠谱的人的组织!'''
金山常年招聘Py/C++人才! http://bit.ly/UoTV 简历直投俺就成;-)
Kenny Yuan
或者，请你告诉大家，你了解多少个程序员在5人以下的国内小软件公司的状况？技术是一回事，现实是另一回事。对这种"超微"的公司来说，在每种现实状况下都能找出最适合的手段把事情做完、做好，才是最重要的。
另外，请你说话请讲究礼节，不要阴阳怪气的，这样对大家都好。
kuku
oliver yang
最早听到每日构建还是8年前。也觉得是个高深的东西，但后来在一家公司管理一个5人的研发团队后，发现，的确是很简单也很实用的东西。
无非就是有台build machine, 再有个scm软件仓库，写一些脚本，把平时基本的测试用例脚本包装起来自动就可以了。
总之，没想象中的复杂。
我现在做的产品，nigthly build的历史恐怕可以追溯到80年代。在大的团队里，nightly
build几乎就是产品的心跳一样，没有nigtly build就是没有心跳，产品就死掉了。
2009/2/16 Kenny Yuan <yuank...@gmail.com>:
--
Cheers,
Oliver Yang
Blog: http://blog.csdn.net/yayong
--------------------------------------------------------------------
Stay Hungry. Stay Foolish.
Stanley Xu
但是这个问题我还是要说，你这样说很没有逻辑，也不是个讨论问题的态度
1.我认为是好的，然后我提出了这些事情的好处，而且我也说了做这么件事的成本，基本上就事1人天的工作
2.我的确不了解多少个程序员在5人以下的公司，我想也了解不了多少。而且daily build从来不是个技术问题，它没有任何技术门槛，恰恰就是个事实问题。事实就是，它能帮你把事情做完做好。如果你觉得不是，请你提出理由，而不是说，这样没用，然后没下文了，这不是讨论问题的态度。
Kenny Yuan
每个人都梦想精英团队，但是在国内常见的那种小公司里面，精英应该说是一个都没有，偶尔有一个有想法想上进的，最终也只能是辞职或者同化。我不是说没有三五个精英开一个小公司然后滚动成大公司的情况，只是太少了，平时见不到。给这种每月挣2000多就满足、20多岁就天天吵着等退休的程序员，向他们推广任何技术都是一件太难的事情：你手下的人不愿意做，领导一般也不支持，一旦搞出问题来还得怪你多事……（除非你是投资人兼经理，但那是另外一个范畴的问题了）
其实五人以下都是一个保守说法，有些更大一些size的公司也是这样的情况。
为了支持一下我的说法，说说样本的大小：以上说法总结自：我自己熟悉的几家小公司，和朋友、同学们了解的几十家其它公司，其中最大的有200多人。
而且我发现，从我2001年开始当项目经理时碰到的那种公司，和现在的同类公司相比，实质上没有多大变化（注：这些公司的利润率有的很高）
Stanley Xu
每个人都梦想精英团队，但是在国内常见的那种小公司里面，精英应该说是一个都没有，偶尔有一个有想法想上进的，最终也只能是辞职或者同化。我不是说没有三五个精英开一个小公司然后滚动成大公司的情况，只是太少了，平时见不到。给这种每月挣2000多就满足、20多岁就天天吵着等退休的程序员，向他们推广任何技术都是一件太难的事情：你手下的人不愿意做，领导一般也不支持，一旦搞出问题来还得怪你多事……（除非你是投资人兼经理，但那是另外一个范畴的问题了）
Kenny Yuan
1、在很多小公司中，对此没有"非用不可"的需求，所以多数就没有采用
2、大型公司因为碰到很多问题，属于"非用不可"的那类公司，所以很多都采用了（或者其它也有效的方案）
3、能解决一些问题，但它不是银弹，不要期望过高
以上三点在我第一贴内就有体现，但是没有说得很清楚，随手一敲就发了。更多的说明请见随后的其它贴子
请注意我没有说每日构建无用。我自己也是此项技术的拥护者，但我不是它的乐观推广者，仅此而已（对很多技术我都如此看待）。希望我说的这些没有伤害技术拥护者的感情。我知道在技术世界里，这样说是很容易引起口水战的，但当时没仔细想，随手写出来，就发了。我本人很讨厌打口水战，如果不出什么意外的话，这里我也不再多回了。
oliver yang
从非技术角度说开的话，其实负责推广这个的人是有相应权力的人，而不是一个普通工程师。
即便是一个普通工程师为公司献策建言，最终也需要技术的负责人的采纳。
这个和公司的size无关，完全是技术领头人的能力和水平的问题。
2009/2/16 Kenny Yuan <yuank...@gmail.com>:
kuku
oliver yang
> 其实逻辑很清楚：
> 1、在很多小公司中，对此没有"非用不可"的需求，所以多数就没有采用
每日构建的需求强烈程度的确和团队的规模成正比，但说小团队没有需求则毫无道理。
因为每日构建的overhead并不大，所以当我养成了习惯后，到了小公司也会自觉使用的。
> 2、大型公司因为碰到很多问题，属于"非用不可"的那类公司，所以很多都采用了（或者其它也有效的方案）
> 3、能解决一些问题，但它不是银弹，不要期望过高
在上规模的软件开发团队中，想保证产品质量和效率，这几乎是必须的方法。
--
Kenny Yuan
不得不放弃的东西太多了，回头有时间我总结一下，列个表格，呵呵，其实有许多例子都很有趣：比如，一个花了半年也没能搞明白如何使用cppunit的人，而我又无权决定HR stuff……
missdeer
能自动检测代码圈复杂度，统计重复代码行，生成代码文档，执行单元测试，生成最终的安装包等，还有lint、cct之类的，也有过一段时间，后来觉得每
次构建耗时太长，价值又不大，就去掉了。我个人窃以为，光是能自动生成安装包这一点，就值得用CI了，即使是一个人的项目又何妨。反而团队规模大了，推
广困难更大，正如各位说的，人的因素才是影响最大的，人越多，不可控因素也会更多。
avalon
linux下，
写点脚本是谁都会的事情。问题是还要做些测试。
对于复杂的测试，比如芯片及其driver开发，QA会运行自动的测试程序，比如ms的
whql程序,
花上一段时间跑完后，可以根据log自动给出报告。ms的驱动自动测试程序作的是
相当的
细腻，背后的工作量相当的惊人，问题是，大多数项目，恐怕需要自己来写这样的
测试程序，
同时你要保障这测试程序的稳定和正确性，说到这里明显就是个成本问题了。
Stanley Xu 写道:
> 好了，我理解你说的问题了。但是放弃daily build这样的best practice的时
> 候，你在这样的公司的时候，你会怎么办？继续想办法推销？还是放弃了混吃等
> 死（为避免歧义，不针对任何人，只是为了说明形象）？还是只是不管怎么样自
> 己用用？
>
> Best wishes,
> Stanley Xu
> http://www.xuwenhao.com
>
>
> 2009/2/16 Kenny Yuan <yuank...@gmail.com
> <mailto:yuank...@gmail.com>>
>
> 每个人都梦想精英团队，但是在国内常见的那种小公司里面，精英应该说是
> 一个都没有，偶尔有一个有想法想上进的，最终也只能是辞职或者同化。我
> 不是说没有三五个精英开一个小公司然后滚动成大公司的情况，只是太少
> 了，平时见不到。给这种每月挣2000多就满足、20多岁就天天吵着等退休的
> 程序员，向他们推广任何技术都是一件太难的事情：你手下的人不愿意做，
> 领导一般也不支持，一旦搞出问题来还得怪你多事……（除非你是投资人兼经
> 理，但那是另外一个范畴的问题了）
>
>
dreamhead
在敏捷软件开发中，从快速反馈的角度来说，每日构建的反馈周期太长了。前两天刚把一个团队的每日构建改成持续集成。
当然，做持续集成最重要一点是遵循CI纪律，也就是，尽量不破坏，一旦破坏，立即修复。
郑晔
2009/2/16 pongba <pon...@gmail.com>:
> 来自：http://program-think.blogspot.com/
> 请大家订阅吧，我就不继续转载了 :)
>
>
> --
> 刘未鹏(pongba)
> Blog | Mind Hacks
> http://mindhacks.cn
> TopLanguage
> http://groups.google.com/group/pongba
>
--
Everything is simple!
oliver yang
>
> 如果这样的build只是compile & link，那是很容易的事情，无论是windows或
> linux下，
> 写点脚本是谁都会的事情。问题是还要做些测试。
>
> 对于复杂的测试，比如芯片及其driver开发，QA会运行自动的测试程序，比如ms的
> whql程序,
> 花上一段时间跑完后，可以根据log自动给出报告。ms的驱动自动测试程序作的是
> 相当的
> 细腻，背后的工作量相当的惊人，问题是，大多数项目，恐怕需要自己来写这样的
> 测试程序，
> 同时你要保障这测试程序的稳定和正确性，说到这里明显就是个成本问题了。
本来就是process的问题，所以一定是由有权力的人去制定和实施的。有权力的意思就是可以做成本的主。而且可以制定规矩，谁也不敢违反。所以，对于一般技术人员，了解一下就可以了，本来这就不是一般人考虑的问题。
>
>
> Stanley Xu 写道:
>> 好了，我理解你说的问题了。但是放弃daily build这样的best practice的时
>> 候，你在这样的公司的时候，你会怎么办？继续想办法推销？还是放弃了混吃等
>> 死（为避免歧义，不针对任何人，只是为了说明形象）？还是只是不管怎么样自
>> 己用用？
>>
>> Best wishes,
>> Stanley Xu
>> http://www.xuwenhao.com
>>
>>
>> 2009/2/16 Kenny Yuan <yuank...@gmail.com
>> <mailto:yuank...@gmail.com>>
>>
>> 每个人都梦想精英团队，但是在国内常见的那种小公司里面，精英应该说是
>> 一个都没有，偶尔有一个有想法想上进的，最终也只能是辞职或者同化。我
>> 不是说没有三五个精英开一个小公司然后滚动成大公司的情况，只是太少
>> 了，平时见不到。给这种每月挣2000多就满足、20多岁就天天吵着等退休的
>> 程序员，向他们推广任何技术都是一件太难的事情：你手下的人不愿意做，
>> 领导一般也不支持，一旦搞出问题来还得怪你多事……（除非你是投资人兼经
>> 理，但那是另外一个范畴的问题了）
>>
>>
>
>
--
xxmplus
2009/2/16 莫华枫 <longsh...@gmail.com>:
> 我这再添一个吧。真事儿哈。
> 元旦前，我们一个项目部署到用户那里。用了几天，总有毛病。一哥们儿天天去客户那里，天天让人骂回来。回来就嚷嚷，什么什么问题，什么什么不行了，就差痛哭流涕了。可家里头什么都好。不行了，时间也不够了，就加班吧。结果一伙人元旦放假三天，加了两天班。抓了几个小bug，建了测试机，没出现过的问题都找到了，可始终没有找出用户那些问题的原因。过了节一上班，项目里的几个主要人物一块儿去了用户那里，一回来就对骂。原来跑客户那哥们儿拿着一个很老的版本给客户装，数据结构和手持设备都不一样，怎么能不出问题呢。
--
Any complex technology which doesn't come with documentation must be the best
available.
Sent from: Vic Australia.
liang
根据工作经验，我写过一篇文字，介绍了每小时构建并测试的实践：
http://smarttesting.spaces.live.com/blog/cns!97093680FB5C09D7!140.entry
On 2月16日, 下午6时15分, pongba <pon...@gmail.com> wrote:
> 来自：http://program-think.blogspot.com/
> 请大家订阅吧，我就不继续转载了 :)
>
> ------------------
>
> 在昨天"正确地做事(善用工具) <http://program-think.blogspot.com/2009/02/6.html>
> "的帖子里提到了代码提交的频度问题。当时我特别强调了"*要保证提交的代码能编译通过*"，
> 理由是"对于每日构建很重要"。我估计列位看官中，不太熟悉每日构建的，大有人在；而且国内停留在手工作坊阶段的软件公司，为数也不少。因此今天我们就来
> 说一下"每日构建"这个话题。假如你平时已经很善于运用"每日构建"这一有效的手段，可以直接略过本系列，去看其它帖子。
> 照例先来说说什么是"每日构建"，每日构建在洋文里也称为Daily Build或者Nightly
> Build。具体定义见"这里<http://en.wikipedia.org/wiki/Daily_build>
> "。简单地讲，就是每天都把*整个*软件项目*自动*
> 编译一遍，最终生成的产出物必须和交付到用户手中的一样（比如你最终提交给用户的是一个安装程序，那就必须在开发过程中每天编译出一个安装包）。
> 为了表明每日构建是一个很有效的手段，我可以给大伙举几个知名软件公司或者著名开源项目的例子：
> 1、微软公司内部几乎所有产品的开发过程，都会使用每日构建。
> 2、我不确定Google是否所有产品都采用，但至少Google的Chrome浏览器是采用每日构建。
> 3、知名的开源组织Mozilla也大量使用每日构建。
> 4、知名的Linux发行版Ubuntu也使用每日构建。
> ......
> 上面这个列表还可以罗列很长。举这么多例子，无非想说，每日构建是一种牛X的软件工程手段。尤其对于复杂项目和大型团队，它的好处更加明显。看到这儿，有同学可-能要问了，具体有些什么好处捏？请看"
> 软件工程进阶之每日构建[1]：好处和优点<http://program-think.blogspot.com/2009/02/daily-build-1-advantage.html>
> "。
>
> 上一个帖子<http://program-think.blogspot.com/2009/02/daily-build-0-overview.html>
> 提到说每日构建是一种很牛X的软件工程手段。本帖子就来说说它到底有多牛X。为了加深大伙儿的印象，我先来说一些陈年往事。
> 话说上世纪末，我还在一家小公司干活，并参与开发了一个C++的项目。当时公司的流程是：开发人员写好代码，自己编译好，丢给测试人员测试；测试人员如果发现b-ug，口头通知开发人员改；开发人员改好bug，再丢给测试人员测试......
>
> ●案例1（开发的混乱）
> 有一天，开发组的小头目找来程序员甲。>>小头目：你负责的XX功能完成了没有？
> >>程序员甲：早做完啦！
> >>小头目：那测试人员甲怎么说一直没看到XX功能？
> >>程序员甲：不会吧！我去瞧瞧。
>
> 若干分钟后，程序员甲回来。
>
> >>程序员甲：不好意思，编译好的EXE我只发给了测试人员乙，忘记发给测试人员甲了。
> >>小头目：!@#$%^&*（此处省略15字）
>
> ●案例2（测试的混乱）
> 另一天刚上班。>>测试人员甲：今天的XX.EXE怎么一运行就崩溃？
> >>测试人员乙：有吗？我这儿好好的呀！
> >>测试人员甲：真见鬼！我找开发问一下。
>
> 经过若干分钟打听，知道XX.EXE是程序员丙负责，于是找来程序员丙。>>测试人员甲：为啥你做的XX.EXE一运行就崩溃？
> >>程序员丙：有这回事？！让我看看你的环境。
>
> 程序员丙在测试人员甲的机器上研究了N刻钟后。>>程序员丙：你是猪脑啊，你没有更新XXX.DLL，害我浪费这么长时间！
> >>测试人员甲：你才是猪脑！我怎么知道XX.EXE会用到XXX.DLL？
>
> 然后两人开始对骂......
>
> ●案例3（集成的混乱）
> 临近项目交付了，开发人员都在忙着改bug，测试人员都在忙着复测bug，没有人手准备安装包，于是安装包的制作一直拖到项目交付的前一天才开始搞。制作安装包-本身倒是很快，半天就搞定。但是......>>小头目：做好的安装包应该没什么问题吧？
> >>测试人员丙：呃，这个，这个......好像装出来的软件没法运行，直接崩溃了。
> >>小头目：偶的神啊！还愣着干嘛，快去查原因！！！今天不搞定大家不许回家！！！
>
> 然后开发和测试通力协作，经过艰苦卓绝的努力，到了午夜时分，终于发现：有个DLL是Debug版本......
> 有同学可能会问：为啥平时测试的时候没发现这个问题捏？因为平时团队里面都使用Debug版本，方便ASSERT断言。到了作安装包那天，照道理应该统
> 一编译Release版本，但是有个家伙遗漏了，所以混了一个Debug版本的DLL在里面。等安装完运行程序时，该DLL动态加载失败，所以程序就崩溃 鸟。
>
> 我上面说的这些情形，到今天为止，还在很多公司内部上演。那为啥每日构建能搞定上面这些问题捏？且听我细细道来：
>
> ●针对"开发的混乱"
> 对于每日构建的流程，开发人员只要负责提交代码到代码库中。不需要挨个给测试人员提供编译后的二进制文件。因此案例1的问题（漏给测试文件）迎刃而解。
>
> ●针对"测试的混乱"
> 在开发阶段，由于测试拿到的程序都是自动编译出来的，因此保证了所有测试人员拿到的是统一的运行程序，并且这个程序和代码库中最新的代码是相对应的。
> 在测试阶段，每一个开发人员修复了Bug之后，都必须把改过的代码提交到代码库，测试人员才会拿到改过Bug的二进制程序。如果某个开发人员改了Bug但是不提-交代码，那么在测试人员看来，相当于他的Bug一直没有改，因此他的Bug就一直不会被关闭。
> 所以案例2的情况也不会出现。
>
> ●针对"集成的混乱"
> 对于每日构建来说，每天都会产生安装包（或者安装光盘的ISO镜像）。也就是说，从项目开始开发的那天起，每天都在进行集成（这就是传说中的*持续集成*
> ）。因此，集成的问题，在一开始就会暴露出来，而不用等到项目后期。
>
> 其实每日构建的好处除了上述三点（这三点我认为比较重要），还有其它很多，大伙儿可以自己再琢磨一下。后面一个帖子，我把每日构建的流程详细介绍一下。
>
> --
> 刘未鹏(pongba)
> Blog | Mind Hackshttp://mindhacks.cn
> TopLanguagehttp://groups.google.com/group/pongba
ShiningRay
1. 人工太便宜
2. 人员素质普遍低
On 2月16日, 下午7时08分, xwssole <xwss...@gmail.com> wrote:
> 大概很多公司都还没有这么先进吧.
>
> 2009/2/16 missdeer <missd...@gmail.com>
守护
On 2月16日, 下午6时15分, pongba <pon...@gmail.com> wrote:
> 来自：http://program-think.blogspot.com/
> 请大家订阅吧，我就不继续转载了 :)
>
> ------------------
>
> 在昨天"正确地做事(善用工具) <http://program-think.blogspot.com/2009/02/6.html>
> "的帖子里提到了代码提交的频度问题。当时我特别强调了"*要保证提交的代码能编译通过*"，
> 理由是"对于每日构建很重要"。我估计列位看官中，不太熟悉每日构建的，大有人在；而且国内停留在手工作坊阶段的软件公司，为数也不少。因此今天我们就来
> 说一下"每日构建"这个话题。假如你平时已经很善于运用"每日构建"这一有效的手段，可以直接略过本系列，去看其它帖子。
> 照例先来说说什么是"每日构建"，每日构建在洋文里也称为Daily Build或者Nightly
> Build。具体定义见"这里<http://en.wikipedia.org/wiki/Daily_build>
> "。简单地讲，就是每天都把*整个*软件项目*自动*
> 编译一遍，最终生成的产出物必须和交付到用户手中的一样（比如你最终提交给用户的是一个安装程序，那就必须在开发过程中每天编译出一个安装包）。
> 为了表明每日构建是一个很有效的手段，我可以给大伙举几个知名软件公司或者著名开源项目的例子：
> 1、微软公司内部几乎所有产品的开发过程，都会使用每日构建。
> 2、我不确定Google是否所有产品都采用，但至少Google的Chrome浏览器是采用每日构建。
> 3、知名的开源组织Mozilla也大量使用每日构建。
> 4、知名的Linux发行版Ubuntu也使用每日构建。
> ......
> 上面这个列表还可以罗列很长。举这么多例子，无非想说，每日构建是一种牛X的软件工程手段。尤其对于复杂项目和大型团队，它的好处更加明显。看到这儿，有同学可-能要问了，具体有些什么好处捏？请看"
> 软件工程进阶之每日构建[1]：好处和优点<http://program-think.blogspot.com/2009/02/daily-build-1-advantage.html>
> "。
>
> 上一个帖子<http://program-think.blogspot.com/2009/02/daily-build-0-overview.html>
> 提到说每日构建是一种很牛X的软件工程手段。本帖子就来说说它到底有多牛X。为了加深大伙儿的印象，我先来说一些陈年往事。
> 话说上世纪末，我还在一家小公司干活，并参与开发了一个C++的项目。当时公司的流程是：开发人员写好代码，自己编译好，丢给测试人员测试；测试人员如果发现b-ug，口头通知开发人员改；开发人员改好bug，再丢给测试人员测试......
>
> ●案例1（开发的混乱）
> 有一天，开发组的小头目找来程序员甲。>>小头目：你负责的XX功能完成了没有？
> >>程序员甲：早做完啦！
> >>小头目：那测试人员甲怎么说一直没看到XX功能？
> >>程序员甲：不会吧！我去瞧瞧。
>
> 若干分钟后，程序员甲回来。
>
> >>程序员甲：不好意思，编译好的EXE我只发给了测试人员乙，忘记发给测试人员甲了。
> >>小头目：!@#$%^&*（此处省略15字）
>
> ●案例2（测试的混乱）
> 另一天刚上班。>>测试人员甲：今天的XX.EXE怎么一运行就崩溃？
> >>测试人员乙：有吗？我这儿好好的呀！
> >>测试人员甲：真见鬼！我找开发问一下。
>
> 经过若干分钟打听，知道XX.EXE是程序员丙负责，于是找来程序员丙。>>测试人员甲：为啥你做的XX.EXE一运行就崩溃？
> >>程序员丙：有这回事？！让我看看你的环境。
>
> 程序员丙在测试人员甲的机器上研究了N刻钟后。>>程序员丙：你是猪脑啊，你没有更新XXX.DLL，害我浪费这么长时间！
> >>测试人员甲：你才是猪脑！我怎么知道XX.EXE会用到XXX.DLL？
>
> 然后两人开始对骂......
>
> ●案例3（集成的混乱）
> 临近项目交付了，开发人员都在忙着改bug，测试人员都在忙着复测bug，没有人手准备安装包，于是安装包的制作一直拖到项目交付的前一天才开始搞。制作安装包-本身倒是很快，半天就搞定。但是......>>小头目：做好的安装包应该没什么问题吧？
> >>测试人员丙：呃，这个，这个......好像装出来的软件没法运行，直接崩溃了。
> >>小头目：偶的神啊！还愣着干嘛，快去查原因！！！今天不搞定大家不许回家！！！
>
> 然后开发和测试通力协作，经过艰苦卓绝的努力，到了午夜时分，终于发现：有个DLL是Debug版本......
> 有同学可能会问：为啥平时测试的时候没发现这个问题捏？因为平时团队里面都使用Debug版本，方便ASSERT断言。到了作安装包那天，照道理应该统
> 一编译Release版本，但是有个家伙遗漏了，所以混了一个Debug版本的DLL在里面。等安装完运行程序时，该DLL动态加载失败，所以程序就崩溃 鸟。
>
> 我上面说的这些情形，到今天为止，还在很多公司内部上演。那为啥每日构建能搞定上面这些问题捏？且听我细细道来：
>
> ●针对"开发的混乱"
> 对于每日构建的流程，开发人员只要负责提交代码到代码库中。不需要挨个给测试人员提供编译后的二进制文件。因此案例1的问题（漏给测试文件）迎刃而解。
>
> ●针对"测试的混乱"
> 在开发阶段，由于测试拿到的程序都是自动编译出来的，因此保证了所有测试人员拿到的是统一的运行程序，并且这个程序和代码库中最新的代码是相对应的。
> 在测试阶段，每一个开发人员修复了Bug之后，都必须把改过的代码提交到代码库，测试人员才会拿到改过Bug的二进制程序。如果某个开发人员改了Bug但是不提-交代码，那么在测试人员看来，相当于他的Bug一直没有改，因此他的Bug就一直不会被关闭。
oliver yang
高晓兵
此致，祝好！
==================================
☆个人求职——意向IT机械行业工程师，教师等
★个人专业博客http://hi.baidu.com/jorbin
==================================
高晓兵