我为什么要夜间建造？
您应该每晚构建以确保您的代码库保持健康.
做夜间构建的一个副作用是它迫使团队创建和维护一个完全自动化的构建脚本.这有助于确保您的构建过程具有文档和可重复性.
自动构建很好地发现了以下问题:
有人检查了破坏东西的东西.
有人忘记检查必要的文件或更改.
您的构建脚本不再有效.
你的构建机器坏了.
每晚这样做可确保您在发生这些问题后的24小时内发现问题.这比在你应该交付软件前24小时找到所有问题更可取.
当然,您还应该为每个每晚构建运行自动单元测试.
我个人发现持续集成比每晚构建更好:http:
//en.wikipedia.org/wiki/Continuous_integration
我甚至在一个人的项目中使用它,令人惊讶的是你能够多快地揭露问题并在那里照顾它们.
我已经做了16年的构建工程(以及其他事情).我坚信构建 - 早期,经常构建,持续集成.因此,我对项目的第一件事就是确定它将如何构建(Java:Ant或Maven ; .NET:NAnt或MSBuild)以及如何管理它(Subversion或其他一些版本控制).然后我将根据平台添加持续集成(CruiseControl或CruiseControl.NET),然后让其他开发人员放松.
随着项目的增长,以及对报告和文档的需求的增长,最终构建将需要更长的时间才能运行.在那时,我将构建拆分为连续构建(在checkin上运行),它只编译和运行单元测试和构建所有内容的每日构建,运行所有报告,并构建任何生成的文档.我还可以添加一个标记存储库的交付构建,并为客户交付做任何其他包装.我将使用细粒度的构建目标来管理细节,以便任何开发人员都可以构建系统的任何部分 - 持续集成服务器使用与任何开发人员完全相同的构建步骤.最重要的是,我们从不提供用于测试的构建或不是使用构建服务器构建的客户.
这就是我做的 - 这就是为什么我这样做(为什么你也应该这样做):
假设您有一个典型的应用程序,包含多个项目和多个开发人员.虽然开发人员可以从一个通用的,一致的开发环境(相同的操作系统,相同的补丁,相同的工具,相同的编译器)开始,但随着时间的推移,他们的环境将会出现分歧.一些开发人员会虔诚地应用所有安全补丁和升级,而其他人则不会.一些开发人员将添加新的(可能更好的)工具,其他人则不会.有些人会记得在建造之前更新完整的工作空间; 其他人只会更新他们正在开发的项目部分.一些开发人员会将源代码和数据文件添加到项目中,但忘记将它们添加到源代码管理中.其他人会编写依赖于环境特定怪癖的单元测试.因此,你会很快看到流行的"嘛,
通过拥有一个独立,稳定,一致,已知良好的服务器来构建应用程序,您将轻松发现这些问题,并且通过从每次提交运行构建,您将能够确定问题何时进入系统.更重要的是,因为您使用单独的服务器来构建和打包应用程序,所以每次都会以相同的方式打包所有内容.没有什么比开发人员向客户提供自定义构建,使其工作,然后不知道如何重现自定义更糟糕的事情.
当我看到这个问题时,首先我搜索了Joel Spolsky的答案.有点失望,所以我打算在这里添加它.
希望大家都知道职业生涯的Joel Test.
从他关于乔尔测试的博客:改进代码的12个步骤
你做日常制作吗？
当您使用源代码管理时,有时一个程序员会意外地检查破坏构建的内容.例如,他们添加了一个新的源文件,一切都在他们的机器上编译好,但是他们忘了将源文件添加到代码库中.因此,他们锁定机器,回家,忘却和快乐.但是没有其他人可以工作,所以他们也必须回家,不开心.
打破构建是如此糟糕(并且如此常见)以至于它有助于进行日常构建,以确保不会忽视任何破损.在大型团队中,确保立即解决破损的一个好方法是每天下午,例如午餐时间进行日常建设.午餐前每个人都尽可能多地办理登机手续.当他们回来时,构建完成.如果它工作,太棒了!每个人都会查看最新版本的源代码并继续工作.如果构建失败,则修复它,但每个人都可以继续使用预构建的,不间断的源代码版本.
在Excel团队中,我们有一个规则,即破坏构建的人,作为他们的"惩罚",负责照看构建,直到其他人破坏它.这是一个不打破构建的好动机,也是一个通过构建过程轮换每个人的好方法,这样每个人都可以学习它是如何工作的.
虽然我没有机会进行日常构建,但我很喜欢它.
还是不相信？查看Daily Builds中的简介是你的朋友!
实际上,您不应该想要的是持续集成和自动测试(这比每晚构建更进一步).
如果您有任何疑问,请阅读Martin Fowler关于持续集成的文章.
总而言之,您希望尽可能早地进行构建和测试,并尽可能立即发现错误,以便修复它们,而您在创建时所实现的目标仍然是新鲜的.
我实际上建议您每次办理登机手续时都要进行构建.换句话说,我建议您建立一个持续集成系统.
这种系统的优点和其他细节可以在福勒的文章和维基百科条目中找到.
根据我的个人经验,这是质量控制的问题:每次修改代码(或测试,可以被视为一种需求形式)时,错误可能会逐渐消失.为了确保质量,您应该重新构建产品因为它将被运送并执行所有可用的测试.这样做的次数越多,允许形成殖民地的可能性就越小.因此,优选每日(夜间)或连续循环.
此外,无论您是将项目的访问限制为开发人员还是更大的用户群,每晚构建都可以让每个人都使用"最新版本",从而最大限度地减少将自己的贡献合并到代码中的痛苦.
京公网安备 11010802040832号 | 京ICP备19059560号-6 