使用构建脚本和持续集成的原因是什么?

如果你没有 continuous integration 您需要等待,直到有人决定执行集成构建,才能发现冲突或不一致的提交。集成构建是一个包含所有开发人员更改的构建。如果每个开发人员都在努力更新他们的本地工作副本,那么您可能不需要常规的集成构建,但实际上,您为什么不将其自动化呢?

测试套件还将有助于发现行为的变化,这些变化会破坏某些东西,但不一定会导致集成构建失败。

这也是标准做法,以执行 smoke test

除了检测破坏事物的冲突和更改外,每晚集成的构建意味着您将始终拥有一个最近的构建,该构建包含了迄今为止每个人的工作。这对于测试和演示来说是一个福音。

这里面也有一些乐趣 thinking up suitable punishments 对于破坏夜间构建的人来说——这意味着他们在没有检查的情况下提交了内容,因此除了解决破坏构建的提交问题之外,他们还应该感到一些痛苦。

这也意味着一旦你 做 开始编写单元测试,您将从中获得更多好处。

还可以看到 answers to this related question .

那么,您如何确保您的同事所做的更改不会破坏任何功能?您是否在每次签入后尝试并测试每个功能?对我来说,实施单元测试可以节省很多时间。

您如何确保两个或多个程序员所做的更改不会干扰下一个在干净机器上进行签出的人无法构建软件?在计划发布之前,认识到这些问题的好时机很短。

许多这些技术背后的原因是要尽早失败,这样你就可以准确地发现并改变那些刚刚使你宝贵的软件停止正常工作的东西。

现在,你不需要连续测试的单元测试,但是它们肯定是你的构建过程的一个重大改进,你一定要考虑阅读并利用它们。

使用CruiseControl和CCTray之类的工具会给你信心,你知道当这个小图标是绿色时,你可以得到最新的代码,而且它很可能与你的本地副本一起工作。

使用自定义构建脚本,同样可以给您信心,因为您可以完成构建,然后运行单元测试、代码覆盖率和fxcop。这一切都提高了代码主体的质量。

拥有专用构建机(将CI、单元测试甚至自动构建放在一边)的关键优势是确保您拥有 清洁的

仅此一点就应该导致更稳定的产品发布。它可以帮助您找到解决方案的问题&代码库在您部署/发布代码库之前。一个常见的例子可能是在开发人员的机器上安装了GAC,但在部署的产品中缺少的组件。

自动构建非常有用,因为它们删除了人工元素——也就是说,它们每次都重复相同的步骤(例如,它们不太容易忘记构建步骤)——这使您具有可预测性。如果使用相同的源运行相同的构建脚本,则应获得相同的输出。这对于适当的发布管理至关重要。

在开发构建环境时,可以对其进行扩展,以向开发团队提供更多支持,尤其是当团队开始成长时。如果您(或您的团队)能够看到降低项目风险或努力的价值,那么其余的可以讨论-实施。

这里的主要优势是更快地解决坏代码库——通常是在人们头脑中仍然清晰的时候(因为理论上,他们只是将更改提交给源代码管理存储库)。然而,人们确实需要关注它。。

简单地说,我们使用它来确保如果有人将代码提交到集成分支/发布分支,并且没有正确测试,我们会在10分钟内发现,而不是10天。

我们不使用它来测试,我们使用它来备份我们的测试过程。