MS 发布管理和发布路径答案

【问题标题】：MS Release Management and Release PathsMS 发布管理和发布路径
【发布时间】：2015-11-10 13:07:33
【问题描述】：

我已经开始深入研究 Release Manager。我见过的几乎（如果不是全部）示例使用类似于 Dev -> Test -> Production 的发布路径。

假设我正在使用 Web 应用程序，而组织并未真正使用持续集成。也许他们每天部署到 Dev 很多次，每周测试几次，每月部署一次生产。（开发和测试实际上是不同的暂存环境。）

因此，通过 Dev -> Test -> Production 的发布路径，您将获得一大堆发布到 Dev，但您不希望所有 Dev 版本都进入测试。因此，在您准备好部署到测试之前，您将不得不拒绝大多数版本。

这里的最佳做法是什么？在您准备好测试/生产之前拒绝发布？创建多个发布路径，例如：

...还是别的什么？

【问题讨论】：

【解决方案1】：

在一个快乐的 DevOps/持续交付世界中，它的工作方式是这样的：

您可以根据需要随时将位推送到 Dev。采摘构建以促进QA的责任是开发者的责任 - 他们应该拒绝他们知道会不会去任何地方的版本。这是开发阶段的部署后（“验证”）步骤。
QA 安排发布到他们的环境（预部署，“批准”）。他们进行测试，并给予祝福（部署后，“验证”）。他们拒绝任何未通过 QA 的版本。
Ops 安排发布到 prod。

如果这是不太可能发生的情况，因为您知道在创建某个“有福的”构建之前，您的所有版本都不是生产候选版本，那么将持续交付的目标阶段设置为“开发”——构建不会进行超出开发环境。当您准备好构建某个 QA 和生产候选对象时，请使用不同的目标阶段进行构建。

【讨论】：

还有一件事。您不需要知道您是否会在构建之前进入“Prod”。即使以“开发”的目标阶段的释放开始和阶段“开发”后得到“释放”，目标可期比进行修改，以进一步继续释放路径。 SPAN>
哦，我忘了你可以指定目标阶段。但是您只能在从 RM 中触发发布时指定目标阶段，对吗？从构建中触发重新释放将始终针对配置中的最后阶段？
@Superhubert 不，当您从构建触发发布时，您可以指定目标阶段。如果您使用的是发布默认模板，它应该是一个选项。