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

Question

我过去使用过持续集成服务器并取得了巨大成功，并且不需要在源代码控制系统上执行代码冻结。

然而，最近我发现，大多数商店在准备发布甚至产品的新测试版本时都在使用代码冻结的概念。 这个想法甚至在我当前的项目中也存在。

当您尽早且频繁地签入并使用单元测试、集成测试、验收测试等时，是否还需要冻结代码？

Answer 1

持续集成是一个“构建”，但它是开发周期的编程部分的一部分。 就像 TDD 中的“测试”是开发周期的编程部分的一部分一样。

作为整个开发周期的一部分，仍然会有构建和测试。

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

因此，您仍然需要冻结代码（或至少冻结一个分支），以确保您所交付的基线符合预期。 仅仅因为有人可以高度自信地实现某些东西，并不意味着它会在不经过相同的最终周期的情况下进入您的版本，而代码冻结是其中的重要组成部分。

使用 CI，您的代码冻结时间可以非常短，因为您的最终构建、测试和发布可能非常可靠，并且代码冻结甚至可能不存在于小型项目中，因为不需要分支 - 您发布并立即返回很快就可以开发下一组功能。

我还想补充一点，CI 和 TDD 允许最终的构建和测试阶段恢复到更接近传统的瀑布式（进行所有开发，进行所有测试，然后发布），而不是进行更持续的 QA对于每周或每月构建的项目。 你的测试人员可以使用 CI 构建来提供早期反馈，但这实际上是与最终测试中不同类型的反馈，在最终测试中，你正在寻找稳定性和可靠性，而不是功能（这显然在单元“测试”中被忽略了）开发商已经建造）。

Answer 2

代码冻结很重要，因为持续集成不会取代运行时回归测试。

构建应用程序并通过单元测试只是挑战的一小部分，理想情况下，当您冻结某个版本的代码时，您签署了两件事：

• 该代码已完全回归，并且没有缺陷
• 该代码完全正确应该在生产中使用的代码（为了符合 SOX 规定）。

如果您使用现代 SCM，只需在此时分叉代码并开始分支中的下一个版本的工作，并在部署项目时进行合并。 （当然，放置一个标签，以便在需要应用中断补丁时可以回滚该点）。

一旦代码处于“发布模式”，就不应再碰它。

我们的典型流程：

Development
   ||
   \/
   QAT 
   ||
   \/
   UAT => Freeze until deploy date => Deploy  => Merge and repeat
            \                                     /
             \- New Branch for future dev -------/

当然，我们在开发过程中通常会有许多并行分支，这些分支在 UAT 之前合并回发布流。

Answer 3

代码冻结更多地与质量检查有关，而不是与开发有关。 代码冻结是 QA 说的：“够了。我们只有足够的带宽来全面测试迄今为止添加的新功能。” 这并不意味着开发人员没有足够的带宽来添加更多功能，只是 QA 需要时间处理静态代码库以确保一切都能协同工作。

如果您都处于持续集成模式（包括 QA），这可能只是很短的一段时间的冻结，而 QA 会在整个包发布之前对其进行最终批准。

这完全取决于您的 QA 和回归测试与开发周期的集成程度。

我赞同已经提到的关于 SCM 分支的投票，并允许开发人员继续使用与 QA 正在测试的代码分支不同的代码分支。 这一切都回到同一件事。 质量保证和回归测试需要在发布前一段时间内有一个静态代码库。

Answer 4

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

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

Answer 5

我听起来像是一个受环境驱动的人，但答案是“这取决于情况”。

代码冻结是一种解决问题的策略。 如果你没有遇到它擅长解决的问题，那么不，不需要它。 如果您有另一种技术来解决该问题，那么不，不需要它。

代码冻结是一种降低风险的技术。 if带来的优点是稳定和简单。 它带来的缺点是

另一种技术是使用分支，例如“特征分支”。 分支的缺点是处理分支和合并更改的成本。

您描述的用于降低风险的技术是自动测试以提供快速反馈。 这里的权衡是速度的提高带来了一些风险的增加（你会错过一些错误）。

在我同意的这些方法中，我更喜欢自动化测试。 但在某些情况下，例如失败成本非常高，代码冻结确实提供了很多价值。