使用持续集成构建设置时,代码冻结是否仍然相关？

Question

我过去使用过Continuous Integration服务器取得了巨大的成功,并且没有必要在源代码控制系统上执行代码冻结.

然而,最近似乎无处不在,大多数商店在准备发布时使用代码冻结的概念,甚至是他们产品的新测试版本.这个想法甚至在我当前的项目中运行.

当您提前和经常办理登机手续,并使用单元测试,集成测试,验收测试等时,仍然需要冻结代码吗？

Answer 1

持续集成是一种"构建",但它是开发周期编程部分的一部分.就像TDD中的"测试"是开发周期的编程部分一样.

作为整个开发周期的一部分,仍然会进行构建和测试.

持续集成和测试的关键是缩短反馈循环并为程序员提供更多可见性.最终,这确实意味着测试和构建中的问题更少,但这并不意味着您不再执行开发周期的原始部分 - 它们只是更有效并且可以提升到更高的级别,因为更多的问题正在进行中在开发周期的早期发现.

因此,您仍然需要冻结代码(或至少是一个分支),以确保您运送的基线符合预期.仅仅因为有人能够高度自信地实现某些东西并不意味着它会在不经过相同的最终循环的情况下进入你的发布,并且代码冻结是其中的一个重要部分.

使用CI,您的代码冻结可能非常短,因为您的最终构建,测试和发布可能非常可靠,并且代码冻结可能甚至不存在于小型项目中,因为不需要分支 - 您释放并返回非常快速地开发下一组功能.

我还想补充一点,CI和TDD允许最终构建和测试阶段恢复到接近传统瀑布(做所有开发,做所有测试,然后发布),而不是更持续的QA已经完成在每周或每月构建的项目上.您的测试人员可以使用CI构建来提供早期反馈,但它实际上是一种不同于最终测试的反馈,在最终测试中,您正在寻找稳定性和可靠性而不是功能性(显然在单元"测试"中错过了开发商已建成).

Answer 2

我认为代码冻结很重要，因为每个新功能都是潜在的新错误来源。当然，回归测试很棒，有助于解决这个问题。但是代码冻结允许开发人员专注于修复当前突出的错误，并使当前的功能集进入值得发布的状态。

最好的情况是，如果我真的想在代码冻结期间开发新代码，我会分叉冻结的树，在那里完成我的工作，然后在冻结后，将分叉的树合并回去。