Azure PaaS 和 ALM - 如何通过单击发布处理分支？
Azure PaaS and ALM - how to handle branches with single-click Publishing?
现在我有一个 Azure PaaS 解决方案，在 TFS 中只有一个存储库 - 我们右键单击从 VS 发布到应用服务，然后交换槽以将代码投入生产。小团队、有纪律的签到（或者我认为如此）等
我决定检查尚未准备好生产的代码，认为如果需要，我可以回滚并在需要时发布修补程序。
好吧，需求出现了，我已经回滚以应用修复程序。不过这有点让人头疼。
我有点不清楚前进的正确方向是什么。我想尝试的是：
- 从我们的 MAIN 存储库创建一个分支，并将所有正在进行的开发都放在那里，称之为
DEV。我们将在我们的机器上创建两个工作区 - 每个分支一个。
- 当我们准备好推送功能时，合并到 MAIN，然后合并到 QA，然后右键单击发布 > 暂存 > 生产。
从高层次上看，这似乎是朝着正确方向迈出的一步？
我想做的是让这个 project/alm 精简。我不想引入带有 RM 和其他昂贵（时间、材料、过程）组件的构建服务器——我只是想对我们当前设置的成熟度进行明智的增量升级，以避免上述问题和这个我能想到的就这些了。
有两种方式供大家参考，一种是基于working flow，一种是基于publish（发布）
一个。仅使用主线和标记发布
优点：
- 避免合并地狱。
- 坚持主线鼓励一些最佳实践，比如适当的
发布计划，不引入大量 WIP，使用分支
处理带外长期工作的抽象，并使用
开放封闭系统和可配置的功能，用于处理
管理可能发生的在建工程；或者可能不会；需要被禁用
现在或将来为了发布或避免完全回滚。
缺点：
- 处理在建工程成为一个问题并增加了潜力
释放时表面攻击区域。但是，如果您的
开发人员受到纪律处分，那么新功能应该是可配置的
和模块化，因此很容易 disabled/enabled，或者没有 WIP
在每个发布点，所有工作都已完成或尚未完成
已经开始（即 Scrum）。
- 大 scale/out-of-band 变化需要提前考虑更多
实施。
乙。按版本分支
优点：
- 您可以在当前迭代开始时开始下一次迭代
迭代完成其一轮验收测试。
缺点：
- 大量树枝。
- 仍然需要在发布点标记分支。
- 仍然需要处理 WIP 并合并之前版本的 WIP
如果它不会成功，则分支到下一个发布分支，并且
仍然需要禁用或将其从发布分支中拉出并重新 运行
验收测试。
- 热修复需要应用到更多分支（发布分支+
hotfix + 新标签将 hotfix 合并到 vnext 分支中，并且可能
vnextnext 取决于修补程序失败的地方。）
关于您的第 1 点。我不建议使用两个工作区，因为您已经 运行 "two workspaces" 内部有两个分支。这种方法并没有那么糟糕，只是在 TFVC 中有点难做，这意味着 TFS 中旧的基于服务器的版本控制。我希望你计划在某个时间点合并从 dev 到 main 的所有内容。
一般来说，您的指南更适合 Git 作为源代码控制，尤其是 gitflow http://nvie.com/posts/a-successful-git-branching-model/ 作为分支模型。我们 运行 在我的团队中取得了成功。
您可以使用 git-tf http://git-tfs.com/
从 TFVC 迁移到 git
如果您正在寻找可通过构建服务器进行横向扩展的廉价模型，我建议您同时查看 Visual studio 团队服务 https://www.visualstudio.com/en-us/products/visual-studio-team-services-vs.aspx 来托管和构建您的代码。您还可以免费集成发布管理（所有 visual studio 订阅者最多 5 people/free）
现在我有一个 Azure PaaS 解决方案，在 TFS 中只有一个存储库 - 我们右键单击从 VS 发布到应用服务，然后交换槽以将代码投入生产。小团队、有纪律的签到（或者我认为如此）等
我决定检查尚未准备好生产的代码，认为如果需要，我可以回滚并在需要时发布修补程序。
好吧，需求出现了，我已经回滚以应用修复程序。不过这有点让人头疼。
我有点不清楚前进的正确方向是什么。我想尝试的是：
- 从我们的 MAIN 存储库创建一个分支，并将所有正在进行的开发都放在那里，称之为
DEV。我们将在我们的机器上创建两个工作区 - 每个分支一个。 - 当我们准备好推送功能时，合并到 MAIN，然后合并到 QA，然后右键单击发布 > 暂存 > 生产。
从高层次上看，这似乎是朝着正确方向迈出的一步？
我想做的是让这个 project/alm 精简。我不想引入带有 RM 和其他昂贵（时间、材料、过程）组件的构建服务器——我只是想对我们当前设置的成熟度进行明智的增量升级，以避免上述问题和这个我能想到的就这些了。
有两种方式供大家参考，一种是基于working flow，一种是基于publish（发布）
一个。仅使用主线和标记发布
优点：
- 避免合并地狱。
- 坚持主线鼓励一些最佳实践，比如适当的 发布计划，不引入大量 WIP，使用分支 处理带外长期工作的抽象，并使用 开放封闭系统和可配置的功能，用于处理 管理可能发生的在建工程；或者可能不会；需要被禁用 现在或将来为了发布或避免完全回滚。
缺点：
- 处理在建工程成为一个问题并增加了潜力 释放时表面攻击区域。但是，如果您的 开发人员受到纪律处分，那么新功能应该是可配置的 和模块化，因此很容易 disabled/enabled，或者没有 WIP 在每个发布点，所有工作都已完成或尚未完成 已经开始（即 Scrum）。
- 大 scale/out-of-band 变化需要提前考虑更多 实施。
乙。按版本分支
优点：
- 您可以在当前迭代开始时开始下一次迭代 迭代完成其一轮验收测试。
缺点：
- 大量树枝。
- 仍然需要在发布点标记分支。
- 仍然需要处理 WIP 并合并之前版本的 WIP 如果它不会成功，则分支到下一个发布分支，并且 仍然需要禁用或将其从发布分支中拉出并重新 运行 验收测试。
- 热修复需要应用到更多分支（发布分支+ hotfix + 新标签将 hotfix 合并到 vnext 分支中，并且可能 vnextnext 取决于修补程序失败的地方。）
关于您的第 1 点。我不建议使用两个工作区，因为您已经 运行 "two workspaces" 内部有两个分支。这种方法并没有那么糟糕，只是在 TFVC 中有点难做，这意味着 TFS 中旧的基于服务器的版本控制。我希望你计划在某个时间点合并从 dev 到 main 的所有内容。
一般来说，您的指南更适合 Git 作为源代码控制，尤其是 gitflow http://nvie.com/posts/a-successful-git-branching-model/ 作为分支模型。我们 运行 在我的团队中取得了成功。
您可以使用 git-tf http://git-tfs.com/
从 TFVC 迁移到 git如果您正在寻找可通过构建服务器进行横向扩展的廉价模型，我建议您同时查看 Visual studio 团队服务 https://www.visualstudio.com/en-us/products/visual-studio-team-services-vs.aspx 来托管和构建您的代码。您还可以免费集成发布管理（所有 visual studio 订阅者最多 5 people/free）