visual-studio - Azure PaaS 和 ALM - 如何通过单击发布处理分支？

Question

现在我有一个 Azure PaaS 解决方案，在 TFS 中有一个存储库 - 我们右键单击从 VS 发布到应用服务，然后交换插槽以将代码投入生产。小团队、严格的签到(或者我是这么认为的)等等。

我决定检查尚未准备好生产的代码，认为如果需要，我可以回滚并在需要时发布修补程序。

好吧，需求已经出现，我已经回滚了一些内容以应用修复程序。不过这有点令人头疼。

我有点不清楚下一步该做什么才是正确的。我想尝试的是:

1. 从我们的主存储库创建一个分支，并将所有正在进行的开发都放在那里，称之为DEV。我们将在计算机上创建两个工作区 - 每个分支一个。
2. 当我们准备好推送某个功能时，请向下合并到 MAIN，然后合并到 QA，然后右键单击发布 > 暂存 > 产品。

从较高的层面来看，这看起来是朝着正确方向迈出的一步吗？

我想做的是保持这个项目/Alm的精益和简单。我不想引入带有 RM 和其他昂贵(时间、 Material 、流程)组件的构建服务器 - 我只想在我们当前设置的成熟度中进行明智的增量升级，以避免上述令人头疼的问题这是我能想到的全部。

Answer 1

有两种方式供大家引用，一种是基于工作流程，一种是基于发布(发布)

A.仅使用主线和标记进行发布

优点:

• 避免合并 hell 。
• 坚持主线可以鼓励一些最佳实践，例如适当的 发布计划，不引入大量 WIP，使用分支 抽象来处理带外长期工作，并使用 开放式封闭系统和可配置的功能来处理 管理可能进行中的工作；或可能不会；需要禁用 现在或将来，以便发布或避免完全回滚。

缺点:

• 处理正在进行的工作成为一个问题并增加了潜力 当需要释放时表面攻击区域。但是，如果您的 开发人员受到纪律约束，那么新功能应该是可配置的 和模块化的，因此很容易禁用/启用，或者没有 WIP 在每个发布点，所有工作要么已完成，要么尚未完成 已启动(即 Scrum)。
• 大规模/带外变更需要提前更多思考 实现。

B.按版本分支

优点:

• 您可以在当前迭代期间开始处理下一个迭代 迭代完成了一轮验收测试。

缺点:

• 大量的分支。
• 仍然需要在发布点标记分支。
• 仍需要处理 WIP 并合并先前版本中的 WIP 如果无法成功，则分支到下一个版本分支并且 仍然需要禁用或将其从发布分支中删除并重新运行 验收测试。
• 需要将热修复应用到更多分支(发布分支 + 修补程序 + 新标签将修补程序合并到 vnext 分支，并且可能 vnextnext 取决于修补程序失败的位置。)