问题描述
正在考虑在一个较大规模的项目中使用Azure DevOps与Gitflow工作流程进行交付。然而，他对一些问题感到困惑，并希望了解其他人的看法。
1. 在多人同时处理一个用户故事时，应该如何使用feature分支和开发者分支来管理任务？是先创建一个feature分支，然后每个开发者再创建自己的分支来处理子任务？完成任务后，是合并回feature分支，还是直接合并回develop分支？这是否是标准实践？
2. 对于每个PR合并到develop分支，是否有必要在Azure DevOps中进行构建？
3. 当一个feature分支与develop分支合并时，是立即发布还是将其作为每晚的构建发布到QA环境？
4. 一般情况下，是构建流程生成构件，还是发布流程完成这一任务？
解决方案
以下解决方案中的操作可能会因版本和组织情况而有所不同，请在操作之前先做好备份。
方案1：选择适合团队的工作流程
Azure DevOps主要是一个团队协作平台，支持多种源代码管理工作流程。选择适合你团队的工作流程需要考虑以下因素：
– 团队成员数量
– 不同特性开发之间的可能冲突
– 发布频率
– 代码/项目复杂性
– 发布管理哲学等
常见的Git工作流程包括GitFlow和GitHub Flow。你的团队需要研究并评估不同的选项，选择最适合你们的工作流程。
方案2：为每个PR进行构建
在Azure DevOps中为每个Pull Request (PR) 合并到develop分支的操作进行构建是一个不错的实践。这样可以确保合并的代码在进行合并前已经通过了构建和测试。Azure DevOps可以配置为要求PR构建通过才能合并，同时你也可以部署PR构建用于初始手动测试和更复杂的集成测试。
方案3：发布策略
关于何时发布取决于团队和项目的需求。有两种常见的做法：
– 即时发布：当一个feature分支合并到develop分支后，立即将发布送往QA环境。这样能快速发现问题并加速修复。
– 夜间构建：将合并后的特性集中作为每晚的构建发布到QA环境。这样可以在一天结束时进行集中测试和验证。
选择哪种策略取决于团队对发布速度和稳定性的偏好。
方案4：构建与发布流程
一般情况下，构建流程负责生成构建工件，而发布流程负责将构建工件部署到不同的环境。在Azure DevOps中，你可以使用构建管道生成构建工件（例如编译代码、运行单元测试等），然后使用发布管道将构建工件部署到不同的环境（例如开发、测试、生产环境）。
根据你的部署目标，你可能需要考虑环境配置管理，以确保在不同环境中运行的应用程序配置正确。这可以通过分离环境无关的构建工件和环境特定的配置来实现，以实现解耦和安全。
请注意，不同类型的应用程序可能有不同的构建和部署策略。例如，对于.NET应用程序，可以使用发布管道自动应用配置变换。对于Docker容器，可以根据环境运行时配置容器实例。
注意：在任何更改之前，请始终确保备份代码和配置，并在非生产环境中进行测试。
结论
选择合适的工作流程、建立良好的构建和发布实践，以及根据团队的需求进行调整，将有助于确保你的项目在使用Azure DevOps与Gitflow时取得成功。对于特定的步骤和操作，请参考Azure DevOps文档和最佳实践。