我正在尝试设计遵循以下原则的新工作流程:
- 只有已通过自动验证(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请求上触发构建.