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

我在过去使用了一个持续集成服务器，取得了巨大的成功，并且从来没有必要在源代码管理系统上执行代码冻结

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

---

当您提前且经常签入，并使用单元测试、集成测试、验收测试等时，是否仍需要代码冻结？

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

---

充其量，如果我真的想在代码冻结期间开发新代码，我会分叉冻结的树，在那里做我的工作，然后在冻结之后，将分叉的树合并回来。

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

让应用程序构建并通过单元测试只是挑战的一小部分，理想情况下，当您为发布冻结代码时，您将在两件事上签字：

• 此代码已完全回归，并且没有缺陷
• 此代码正是应该在生产中使用的代码（用于SOX合规性）

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

一旦代码处于“释放模式”，就不应触摸它

我们的典型流程：

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

---

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

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

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

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

因此，您仍然需要进行代码冻结（或至少是分支），以确保您所发布的内容的基线符合预期。仅仅因为有人能够以高度自信的方式实现某些东西，并不意味着它进入您的发行版时没有经过相同的最终周期，而代码冻结是其中的一个重要部分

有了CI，您的代码冻结时间可能很短，因为您的最终构建、测试和发布可能非常可靠，而且代码冻结甚至可能不存在于小项目中，因为不需要分支—您可以很快地发布并重新开发下一组功能

---

我还想补充一点，CI和TDD允许最终的构建和测试阶段更接近传统的瀑布式（完成所有开发，完成所有测试，然后发布），而不是对每周或每月构建的项目进行更持续的QA。您的测试人员可以使用CI构建来提供早期反馈，但这实际上是一种不同于最终测试的反馈，在最终测试中，您寻求的是稳定性和可靠性，而不是功能性（开发人员构建的单元“测试”中显然遗漏了这一点），只是QA需要时间和静止的代码库来确保一切都能协同工作

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

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

---

我支持前面提到的关于SCM分支和允许开发人员继续使用不同于QA测试的代码分支的投票。这一切都可以追溯到同一件事。QA和回归测试在发布之前需要一段时间的静态代码库。

我听起来像是一个上下文驱动的人，但答案是“这取决于”

代码冻结是一种处理问题的策略。如果你没有问题，它很擅长解决，那么不，它是不需要的。如果你有另一种解决问题的方法，那就不需要了

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

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

您描述的降低风险的技术是自动测试，以提供快速反馈。这里的权衡是增加速度以增加风险（您将错过一些bug）

---

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

这是我的印象。还有，我想既然你