读这篇文章让我感到疑惑; 对于一种情况而言,夜间建筑是否比持续整合更好？对于持续整合,答案的共识似乎是相当不平衡的,是传福音还是当持续整合是一种选择时,是否真的没有理由使用夜间构建？
如果你真的在与所有可用的测试进行持续集成,那么夜间构建将是多余的,因为那天检查的最后一件事已经过测试.
另一方面,如果您的CI机制仅涉及运行所有可用测试的子集,例如因为您的某些测试需要很长时间才能运行,那么您可以使用nightlies另外运行所有测试.这样可以让你及早发现许多虫子,如果你不能及早捕捉它们,你至少可以在一夜之间捕获它们.
但是,我不知道,如果技术上仍然是CI,那么每次只做一次"部分"构建,忽略一些测试.
在我们的组织中,夜间构建和CI构建有两个不同的目的.CI构建是一个"最新代码"构建,其中单元测试将按照您的预期在最后一次检入中运行.我们还在CI构建上运行了几个代码度量标准.
但是,对于夜间构建,我们只包含已通过同行评审过程并准备进行测试的源代码.
这样,每晚构建总是包含用于测试的"功能就绪"的构建,而CI构建包含功能(在单元测试通过的范围内)可能尚未准备好发送到测试组的功能.
测试组仅从其中一个夜间构建中编写新CR,而不是CI构建,尽管这些CR也可用于非正式探索型测试.
是的,如果您有一个想要附加到构建的进程,但它是资源很重的.例如,在我的团队中,我们在夜间构建期间运行JTest.我们不能在白天运行它,因为:
它需要大量资源,而这些资源可能无法使用
每次完成需要4个小时
京公网安备 11010802040832号 | 京ICP备19059560号-6 