使用连续集成构建程序时代码冻结是否仍然相关?

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

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

持续集成和测试的重点是缩短反馈循环,让程序员更容易看到。最终,这确实意味着测试和构建中的问题更少,但这并不意味着你不再做开发周期的原始部分——它们只是更有效,并且可以提升到更高的级别,因为更多的活动问题在开发周期的早期被捕获。

因此,您仍然需要有一个代码冻结(或至少一个分支),以确保您的航运的基线是预期的。仅仅因为某人能够以高度的自信实现某事并不意味着它进入你的释放而不经过相同的最后循环,而代码冻结是其中的一个重要部分。

使用ci,代码冻结可能非常短,因为您的最终构建、测试和发布可能非常可靠,而且代码冻结甚至可能不存在于小项目中,因为不需要分支-您可以很快地发布并重新开始下一组功能的开发。

我还想补充一点,ci和tdd允许最终的构建和测试阶段回归到更接近传统瀑布(完成所有开发,完成所有测试,然后发布)的阶段,而不是在每周或每月构建的项目上进行更连续的qa。您的测试人员可以使用ci构建来提供早期反馈,但它实际上是一种不同于最终测试的反馈,在最终测试中,您需要的是稳定性和可靠性,而不是功能性(这显然是在开发人员构建的单元“测试”中遗漏的)。

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

拥有一个应用程序构建并通过单元测试只是挑战的一小部分,理想情况下,当您冻结一个版本的代码时,您需要完成两件事:

• 此代码已完全回归,并且没有缺陷
• 这个代码正是应该在生产中使用的代码(为了符合sox)。

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

一旦代码处于“发布模式”,就不应该被触摸。

我们的典型流程:

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

当然,在开发期间,我们通常有许多并行分支,它们在uat之前合并到发布流中。

代码冻结与qa的关系比与dev的关系更大。代码冻结是qa说:“够了。我们只有带宽才能充分测试到目前为止添加的新特性。“这并不意味着DEV没有带宽来增加更多的特性,只是QA需要用静态代码库来确保所有的工作一起工作。

如果你都在持续整合模式(包括QA),这可能只是一个很短的时间冻结,而QA将最后的印章批准在整个包就在出门前。

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

我支持前面提到的关于scm分支和允许dev在不同于qa测试的代码分支上继续工作的投票。一切又回到了同一件事上。qa和回归测试在发布之前需要一段时间的静态代码库。

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

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

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

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

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

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

您描述的降低风险的技术是自动化测试,以提供快速反馈。这里的折衷方案是提高速度以增加风险(您将错过一些bug)。

在这些方法中,我更喜欢自动化测试。但也有一些情况,例如失败的成本非常高,代码冻结确实提供了大量的价值。