代码冻结是否违反了连续交付的原则？

Question

下面是git-flow，

---

使用SDLC的CI / CD方法，如果加标签的提交通过了质量检查管道，那么该是从 Develop分支创建 Release分支的时候了，因为我的理解是，

如果在与 Master分支合并时生产管道构建失败，则开发人员需要首先解决该问题，并在同一 Release 分支上创建一个新的工作提交。这可能会导致开发人员在 Develop 分支中合并代码的冻结时间，原因是 Release 分支与 Develop 分支合并（在生产管道之后）取得成功）一定不要在开发管道中抛出错误。

---

我的问题是，如下所示，

Master合并持续时间是否需要 Develop 分支上其他开发人员的代码冻结时间？如果是，codefreeze是否打破了连续交付的principles？

Answer 1

是的，我认为这种方法与CI原则大不相同。它可能属于CI Theatre范围。没有CI，您就无法真正谈论CD。

CI背后的总体思想是，将所有开发都分解为细微的，渐进的变化，并尽可能靠近分支的尖端进行开发，并立即集成到分支中，以最大程度地提高可见性并最大程度地减少意外。只有在这种情况下，CI工具才能有效地指出大多数问题的提交速度。

在主分支保持移动的同时离开侧分支（冻结或不冻结）意味着将分支与主分支合并（在任何方向上）需要付出额外的努力，难度随侧分支的寿命成比例增加。那是因为合并尝试将两个更大的块粉碎在一起：分支中的所有提交和自分支被拉/同步以来在master上完成的所有提交-不再是增量更改。立即识别错误提交的能力将丢失，这是一个全有或全无的决定：您允许合并，接受质量较高的结果还是拒绝它。 这就是为什么恕我直言：

• 谈论在分支上进行CI几乎是可疑的
• CI（作为一种方法）与trunk-based development (TBD)几乎是同义的。

发布分支与常规分支有些不同，在某些业务案例中它们可能很有意义。但前提是它们不受合并影响而仍然适用于CI。实际上，发行分支的要点是冻结-将其与主干上的开发隔离开来，并继续发展到下一个发行版。将发行分支合并回主干对我来说没有多大意义：旧版本的更改不一定与新版本兼容，这样的合并只会带来麻烦。另请参见my answer to How to get rid of develop branch for simplified Git flow。如果发布分支上有有价值的提交（请求这种合并的通常原因），则应对其进行兼容性验证，并在中继中作为独立更改进行两次提交，并与其他任何中继更改一样提交相同的验证标准。

注意：我并不是说非配置项策略不起作用-它们大多数都可以（我与他们合作了多年），但是它们更难，更慢，更昂贵。