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 取决于修补程序失败的位置。)