我正在使用VSTS进行源代码管理，CI和发布管理 我只想构建一次代码而不是每个环境或分支。 发布渠道是： Dev - ＆gt; QA - ＆gt; PROD
我只有一个分支或密码库，团队提交更改。当修复程序的所有代码都准备就绪时，CI会触发Build。我创造 发布并通过管道将其推广，直到将其部署到生产中。
我需要知道一个分支对我们是否合适，所以如果我们要修复一些错误或创建一个新功能，只需创建一个子分支并每天将代码提交给Master Branch。
我试图避免为每个环境使用3个分支。我认为CI和发布管理使我们能够从以前的版本中创建版本。
那么，在我的案例中，两种方法（3个分支机构或仅有一个主分支机构）的缺点和优点是什么？
答案 0 :(得分：2)
每个环境不需要分支，但您需要问自己一些关于开发过程的问题。
您多久发布一次新功能？您是否拥有全面的单元，集成，回归和用户验收测试，这些测试完全自动化并在每次检入时运行？
如果您开发了新功能但没有完整的自动化测试，那么您可能至少还需要一个分支。 1开发新功能，1支持实时代码库。阅读ALM Rangers branching guidance并从那里开始。
答案 1 :(得分：0)
通常，一个发布管道应该只有一个分支。您可能在一个管道中有多个环境，但部署到它们的版本应该是相同的，因为版本管道反映了一个过程，即您的软件在构建后最终如何发布。例如，该版本首先部署到QA环境进行测试，并且只有在通过QA环境测试后才能部署到生产服务器。 QA使用一个分支的构建并且Prod使用另一个分支的构建是没有意义的。有关详细信息，请参阅此链接：Where to deploy? Environments in Microsoft Release Management。
对于分支机构，它是关于您的开发过程。以下是MSDN的一些建议供您参考：
团队何时应该添加分支？
您应该在以下情况下创建分支：
当您必须以不同的时间表/周期发布代码时 现有分支机构。
当您的代码需要不同的分支政策时。如果你创建一个新的 拥有新政策的分支机构，您可以为您的战略增添战略价值 项目
当功能发布给客户并且您的团队计划 进行不影响计划发布周期的更改。
您不应该为每个用户故事创建分支，因为它 创造了高集成成本。虽然Team Foundation Server可以 分支容易，管理分支的开销可以变成 如果你有很多分支，那就很重要。
查看此链接了解详情：Branch strategically