从每日构造到持续继承

    我总是向别人强调每日构造的重要性，也总是强调要自动化－－自动化到一次双击，或者一个脚本，就能生成软件的安装包，甚至软件的部署！是的，对于需要部署的软件来说，安装包不是终点，每日构造成功的标志是的部署成功，并且冒烟测试通过。如果这一切任何一个步骤出了问题，那都意味这心跳骤停！
    然而，我的这种宣传并没有起到很好的效果，很多人认为，每日构造，就是每日生成release版本的二进制文件，email一下构造日志就OK了。甚至，这种构造和email构造日志还是人工产生的！！多么可笑，对于程序员来说，这到象是裁缝光屁股开店，鞋匠光脚赶路了。在推销员吹嘘他的产品多么伟大时，我们必须看看他是如何向自己提供“伟大”的产品的。
　　对任何一个有能力的开发组织来说，构造一个全过程的每日构系统，决不是很困难的。我仍然不是很明白，为什么那么多的开发者不能明白这一点？今天再次看到“持续集成”这个词，似乎有点启发，每日构造的“构造”意思太过于强调“产生“，也许”持续集成”是个更好的词汇。我是不是该两个词同时使用，以表达我要把构造持续到部署成功和通过冒烟测试的真实意图？有人说：语言能走多远，我们的思想就能走多远。然而我仍然很担心，别人在听到的我的建议的时候，把注意力放到集成上，有意或无意地忽略持续呢？或者只是简单的把“持续”理解为每天都作的事情呢？
　　有时候，觉得很悲哀，对于每日构造这样一件简单而有效的机制，为什么都需要说那么多，而不能够真正做好？在今天，大多数人都会使用ＶＣＳ系统，但是，正确使用的有多少？有多少人能够在２０分钟内，回退到任何一个历史版本上？多少人已经不再需要手工参与代码的备份、验证、构造、错误报告机制当中去？一方面，我们声称给别人“最有价值”的程序，另一方面，却写不出一个最简单的，为自己服务的脚本，这难道不是讽刺吗？
　　外面下着雨，天空是灰色的。软件的天空也一样，至少，我所看到的如此之多的地方，都是这样的。我们一面惊讶，不屑于印度软件的崛起，一面羡慕，向往于美国的软件技术的发达，另一方面，一边痛恨自己国家的软件业阳痿，一面以自己痛恨的方式，写下自己痛恨的软件。
　呜呼哀哉！