我正在使用 VSTS 进行源代码控制、CI 和发布管理 我试图只构建一次代码，而不是每个环境或分支。 发布管道是： 开发 -> 质量检查 -> 产品
我只有一个分支或代码库，团队在其中提交更改。当修复的所有代码都准备好时，CI 会触发构建。我创造 发布并通过管道进行推广，直到将其部署到生产环境中。
我需要知道一个分支是否适合我们，所以如果我们要修复一些错误或创建一个新功能，只需创建一个子分支并将代码每天提交到主分支。
我试图避免为每个环境使用 3 个分支。我认为 CI 和发布管理为我们提供了从以前的版本创建发布的能力。
那么，就我而言，这两种方法（3 个分支或只有一个主分支）的优缺点是什么？
【问题讨论】：
标签： version-control continuous-integration azure-devops branching-and-merging ms-release-management
通常，一个发布管道应该只有一个分支。您可能在一个管道中有多个环境，但部署到它们的版本应该相同，因为发布管道反映了您的软件在构建后如何最终发布的过程。例如，发布首先部署到 QA 环境进行测试，只有在 QA 环境测试通过后才能部署到生产服务器。 QA 使用一个分支的构建而 Prod 使用另一个分支的构建是没有意义的。详情可参考此链接：Where to deploy? Environments in Microsoft Release Management。
对于分支，它与您的开发过程有关。以下是 MSDN 的一些建议供您参考：
团队应该何时添加分支？
您应该在以下情况下创建分支：
当您必须在与 现有分支机构。
当您的代码需要不同的分支策略时。如果你创建一个新的 拥有新政策的分支机构，您可以为您的企业增加战略价值 项目。
当功能发布给客户并且您的团队计划 进行不影响计划发布周期的更改。
您不应该为每个用户故事创建一个分支，因为它 集成成本高。尽管 Team Foundation Server 使 分支很容易，管理分支的开销可以变成 如果你有很多分支，这很重要。
查看此链接了解详情：Branch strategically
【讨论】：
你不需要每个环境都有一个分支，但你需要问自己一些关于你的开发过程的问题。
您多久发布一次新功能？您是否有全面的单元、集成、回归和用户验收测试，这些测试完全自动化并在每次签入时运行？
如果您开发新功能并且没有一整套很棒的自动化测试，那么您可能至少需要多一个分支。 1 开发新功能，1 支持实时代码库。阅读ALM Rangers branching guidance 并从那里开始。
【讨论】：