强制执行代码审查并使集成分支保持原始状态的工作流(git,Stash,TeamCity)

Question

我正在尝试设计遵循以下原则的新工作流程:

• 只有已通过自动验证(CI)的提交才应合并到主线中(具体而言,合并状态应通过CI以使集成分支尽可能保持原始状态)
• 只有通过人工代码审查的提交才应合并到主线中
• 只有通过自动验证的提交应该由另一个人审查(如果它甚至没有构建和通过测试,不要浪费别人的时间)
• 功能分支应该由CI覆盖(独立,不合并到集成分支 - 这对开发期间的开发人员有帮助)

我们正在使用git,Stash和TeamCity.这就是我想出来的,但它们都不是完美的.我正在寻找对我的建议或新想法的调整.

工作流程1

• 开发人员在功能/ VHPC-1上开发(功能分支由TeamCity中的常规CI覆盖)
• 功能完成后,开发人员会创建一个拉取请求:feature/VHPC-1 - > mainline

• 当拉取请求被另一个开发人员批准时,它会被Stash自动合并到主线中(主线由TeamCity中的普通CI覆盖)

• 问题:如果存在合并冲突,Stash将不会执行合并,但直到合并到主线之后才会测试合并状态.我们不知道主线是否会发生故障.

工作流程2

• 开发人员在功能/ VHPC-1上开发(功能分支由TeamCity中的常规CI覆盖)
• 开发人员从功能/ VHPC-1推送到功能/ VHPC-1 /审查(我们重新设置集成分支,然后执行CI(测试合并状态))
• 功能完成后,开发人员会创建一个拉取请求:feature/VHPC-1/review - > mainline

• 当拉取请求被另一个开发人员批准时,它会被Stash自动合并到主线中(主线由TeamCity中的普通CI覆盖)

• 问题:测试合并状态之间的时间(20分钟 - 1天？),并且集成发生允许集成分支中的更改,这可能意味着合并状态不再起作用.整合分支破裂的机会.

• 问题:分支数量的两倍意味着一些额外的复杂性和工作.

工作流程3

• 开发人员在功能/ VHPC-1上开发(功能分支由TeamCity中的常规CI覆盖)
• 功能完成后,开发人员会创建一个拉取请求:feature/VHPC-1 - > feature/VHPC-1/review

• 当另一个开发人员批准并合并拉取请求时,feature/VHPC-1/review将在合并状态下自动构建和测试,并在成功时自动充当主线

• 问题:分支数量的两倍意味着一些额外的复杂性和工作.

• 问题:提交必须始终集成到主线中,并且只能选择发布分支.

工作流程4

• 开发人员在功能/ VHPC-1上开发(功能分支由TeamCity中的常规CI覆盖)
• 功能完成后,开发人员创建一个拉取请求:feature/VHPC-1 - > mainline TeamCity会自动添加一个审阅者,并尝试构建并测试拉取请求 - 处于合并状态(使用Stash的未记录的refs/pull) -REQUESTS /合并)

• 如果自动验证通过,TeamCity将批准拉取请求.然后,人可以审查,批准并将其合并到主线中.

• 问题:TeamCity监视refs/pull-requests/merge,当集成分支发生变化时,这会改变,这意味着当集成分支获得一个新的更改时,将在所有打开的pull请求上触发构建.

Answer 1

这里是前 Stash 开发人员。只是一些一般性的想法。

Stash 团队（以及我合作过和观察过的大多数团队）进行“乐观”分支构建。也就是说，他们构建源分支的假设/希望是，如果它干净地合并，它可能不会破坏主线构建。根据我的经验，情况几乎总是如此。

一些选项：

1. 什么也不做 - 如果/当主线最终崩溃时快速修复它
2. 除了自动恢复任何生成红色构建的合并提交之外什么都不做（并且可能首先手动执行）
3. 要求 PR 合并只能快进，开发人员需要在合并回来之前手动从主线重新建立基础/合并
4. 在 Stash 中添加一个自定义的网守插件/按钮，以便“集成后合并绿色构建”，这会在进行实际合并之前首先执行一次性合并构建。

我同意，一般来说，从 Stash 隐藏的“合并”引用进行构建，取决于拉取请求打开的时间，可能会导致太多构建（正如您所指出的）。

不确定这是否有帮助？