最近，我的初出茅庐的团队（只有两个开发者）试图实施Jez Humble描述的持续交付实践。
那就是我们抛弃了功能分支和拉取请求（在git中），并且每天至少都要提交主线分支。
我们有一个全面的单元和功能测试套件，用于前端和后端，当推送到git时由Jenkins自动触发。
我们配置了功能切换应用，并决定将其用于更长时间运行的功能。
然而，我们遇到了一些问题，我很想从成功使用这种方法的人那里获得一个观点。
由审核/手动质量检查流程导致的延迟 通常任务足够小，以至于我们认为他们不保证配置功能切换，例如向表单添加额外字段或更改某些字段标签。但是，由于各种原因，票证将被阻止（例如，需要UX输入的任务的某些无法预料的方面）。
这意味着主线最终处于受损状态，同时我们等待外部依赖关系来解锁任务。通常我们会说“我们不能在星期四之前部署任何东西，因为那时我们可以进行IA审查”
这里的答案可能是对开始执行哪些任务的更严格的审查。但是，通常很难完全预测每个潜在的阻挡者。也许如果任务被阻止，应该添加一个功能开关来添加功能开关，还是恢复提交？棘手的情况。
主线分支集成期间的代码审核问题
分支和拉取请求可以很好地分解对单个任务所做的更改。然而，在尝试CD时，我们最终在主线上进行了一些不相关的提交，并且代码审阅者不得不以某种方式拼凑在一起提交与他正在审查的任务相关的提交。并且通常会有一些额外的小错误修复，在任务结束时响应审核类型提交的更改。从本质上讲，我们无法通过这种设置找到一种干净的代码审查工作方式。
通用代码审核问题
我们使用phabricator进行提交后代码审查，但发现它标记了每次提交（一些非常小的）代码审查，而不是向我们显示每个单独的开发任务的更改列表。因此，与git pull请求相比，它审查了代码繁琐。有更好的方法吗？
我们现在已经恢复到git中的短期功能分支并提升拉取请求以启动代码审查，这是一个很好的设置，但如果我们能解决我们对非功能分支CD的问题，那么我们想重新尝试这种方法。
答案 0 :(得分：0)
如果在完成任务时使用功能分支来处理任务，则可以将其合并回集成分支，或者创建拉动请求以将合并返回到集成分支。
在这两种情况下，您都会收到合并提交，这是您在功能分支上所做的每项更改的摘要。
你还需要更多的东西吗？
答案 1 :(得分：0)
您可以在整合之前自动执行审核流程和/或运行它。如果您自动执行审查过程，例如，要添加表单/按钮等，您只需要一套测试来运行后集成以验证主线是否已损坏
您需要在集成之前进行代码审查，即拉取请求。如果在代码审查期间捕获并修复了问题，则会更新拉取请求并且主线不会混乱。
代码审核工具非常适合一组开发人员和团队需求。我建议您使用一些代码审查工具来查看哪一个适合您的需求
根据您的大多数问题，我建议您在合并之前运行所有的审核/代码审核等。（如果流程过于繁琐，您可以按增量执行）并为所有内容运行自动化测试套件你希望做后期整合。
如果您团队中的流程设置太复杂，无法在一天内完成并且可以进行多次迭代，那么评估gitflow的修改版本而不是基于派生的CI模型是值得的