问连续积分痛点

EN

最近，我刚起步的团队(只有两个开发人员)试图实现Jez描述的持续交付实践。

也就是说，我们放弃了特性分支和拉请求(在git中)，并且至少每天都要提交到主线分支。

我们有一个全面的单元和功能测试套件的前端和后端，这是自动触发詹金斯时，推动git。

我们配置了一个功能切换应用程序，并决定将其用于运行时间较长的功能。

然而，我们遇到了一些问题，我很想从成功地使用这种方法的人那里获得一个视角。

1. 由于审核/手动QA流程而导致的延迟()通常很小，以至于我们认为它们不值得配置特性切换，例如在表单中添加一个额外的字段，或者更改一些字段标签。但是，由于各种原因，票证会被阻塞(例如，任务中需要UX输入的一些不可预见的方面)，.This将意味着主线最终处于妥协状态，而我们则等待外部依赖关系解除对任务的阻塞。我们经常会说：“我们在周四之前什么都不能部署，因为那时我们就可以得到IA审查了。” 这里的答案可能是对哪些任务开始进行更严格的审查。然而，往往很难完全预料到每一个潜在的阻断剂。也许，如果一个任务被阻塞了，那么应该执行额外的dev来添加一个特性开关，或者恢复提交？棘手的情况。
2. 在主线分支集成过程中的代码评审问题 分支和拉请求可以很好地分解对单个任务所做的更改。然而，尝试CD时，我们在主线上得到了一个由不相关的提交组成的mash，而代码审阅者不得不以某种方式将与他正在审查的任务相关的内容提交到一起。而且通常还会有一些额外的小错误修复，在任务结束时响应评审类型提交而进行的更改。本质上，我们无法找到一种清晰的方法来用这个设置编写代码评审工作。
3. 泛型代码评审问题 我们使用phabricator进行了一段时间的后提交代码评审，但发现它标记了每个提交(一些非常小的)代码评审，而不是显示每个开发任务的更改列表。因此，与git拉请求相比，它使得查看代码变得非常麻烦。有更好的办法吗？

现在，我们又回到了在git中的短暂特性分支，并提出了启动代码评审的拉请求，这是一个很好的设置，但是如果我们能够解决我们使用非功能分支CD时遇到的问题，那么我们想重新尝试这种方法。