问题描述
所在的团队目前正在使用Gitflow工作流程，将代码集成到develop分支中。团队使用Azure Repos和Azure DevOps来构建和部署SQL Server数据仓库的代码，涵盖了SSIS、SSAS以及30多个数据库。目前，他们的部署流程是先部署到集成服务器，然后再部署到生产服务器。他们有一个自动构建的SQL Server解决方案，会在提交到develop分支时触发构建，然后手动运行构建以生成部署脚本。所有的SSAS和SSIS构建和部署都是在提交到分支时触发的。
用户希望将工作流程迁移到使用Pull Request，这样就不会有破损的构建阻碍其他人的部署。如果有人在develop分支上破坏了构建，那么按照当前的方法无法部署。
在迁移到Azure DevOps之前，用户使用发布工作流程手动创建部署工件，并且所有部署都是手动进行的。虽然这个过程非常繁琐和耗时，但是用户想要找到一条迁移到Pull Request的道路。用户目前的团队在使用VSCode来创建功能特性，这一部分已经很好地运作。用户正在寻求关于使用Pull Request进行迁移的建议。
解决方案
请注意以下操作可能因Azure DevOps版本或其他因素而有所不同。
使用Pull Request和Branch Policies
如果你希望在合并之前进行构建验证，你可以在develop分支上设置”Branch Policies”，这将要求在Pull Request通过之前成功完成构建。
步骤：
- 打开Azure DevOps中的你的项目。
- 进入”Repos”，选择”Branches”。
- 选择”develop”分支，然后点击”Branch policies”。
- 在”Build validation”部分，启用”Builds”选项，并选择一个用于验证的构建定义。
- 确保选择的构建定义能够编译代码并运行单元测试等基本检查。
- 保存更改。
现在，当有人创建一个Pull Request时，相关的构建定义会运行以确保代码通过基本检查。如果构建失败，Pull Request将无法完成合并。
持续集成和持续交付
在迁移到使用Pull Request的工作流程时，你可以考虑以下几点：
持续集成（CI）：在Pull Request创建时运行一个轻量级的构建，检查代码是否编译通过和单元测试是否通过。这有助于避免破坏主分支的情况。
持续交付（CD）：考虑使用自动化的部署流水线，将通过验证的Pull Request自动部署到集成环境，以便进行更全面的测试。一旦通过所有测试，你可以手动将代码部署到生产环境。
迁移Gitflow：你不一定需要完全放弃Gitflow工作流程。你可以将Gitflow的一些概念与使用Pull Request的工作流程结合使用。例如，你可以使用Gitflow中的feature分支来创建Pull Request，并在验证通过后将其合并到develop分支。
请记住，迁移到新的工作流程需要团队的共同努力和适应，同时需要在持续集成、持续交付和代码质量方面进行一些调整和优化。
在迁移过程中，建议先在开发环境或小范围内进行试验，以确保新的工作流程能够顺利运行。
关于合并到主分支
你提到了关于如何合并到主分支的问题。根据你的需求，你可以选择以下几种方法：
从develop分支创建一个release分支，然后将准备完成的提交(cherry-pick)到release分支。这允许你在release分支上对代码进行进一步的测试和准备，然后再将release分支合并到主分支。
如果你正在探索更倾向于基于主干的开发（trunk-based development），那么你可以直接在主分支上创建Pull Request，通过CI/CD流水线进行测试和部署，而不必通过release分支。
根据你的团队工作流程和项目需求，选择最适合的方法进行合并。
请注意，使用cherry-pick可能会引入代码分歧，需要小心管理。在选择合并方法时，请考虑团队的技术水平和工作习惯。
总结
通过在develop分支上设置Branch Policies和运用持续集成、持续交付的原则，你可以将工作流程迁移到使用Pull Request的方式。你可以根据团队的需求和项目特点，灵活选择合适的合并方法和工作流程，以提高团队的开发效率和代码质量。
请在迁移过程中，充分测试和备份，以确保顺利完成迁移并避免潜在的问题。
总结
迁移到使用Pull Request的工作流程可以帮助团队更好地管理代码集成和部署过程，避免破损的构建阻碍部署。通过设置Branch Policies、持续集成和持续交付，以及选择适合团队的合并方法，你可以实现更高效、高质量的开发流程。记住，迁移工作流程需要团队