MS 发布管理和发布路径
MS Release Management and Release Paths
我已经开始深入研究 Release Manager。我见过的几乎（如果不是全部的话）示例都使用类似于 Dev -> Test -> Production 的发布路径。
假设我正在使用 Web 应用程序，而组织并没有真正使用持续集成。也许他们每天部署到 Dev 多次，每周测试几次，每月部署到 Production 一次。 （开发和测试实际上是不同的暂存环境。）
因此，使用 Dev -> Test -> Production 的发布路径，您将获得一大堆发布到 Dev，但您不希望所有 Dev 发布都进入测试。因此，在您准备好部署到测试之前，您将不得不拒绝大部分发布。
此处的最佳做法是什么？在您准备好 Test/Production 之前拒绝发布？创建多个发布路径，例如：
- 开发
- 开发 -> 测试
- 开发 -> 测试 -> 生产
...或其他？
在快乐的 DevOps/continuous 交付世界中，它的工作方式是这样的：
- 您可以随心所欲地向 Dev 推送位。选择构建以提升为 QA 的责任是开发人员的责任——他们应该拒绝他们知道不会有任何进展的版本。这是开发阶段的post-部署（"Validation"）步骤。
- QA 安排发布到他们的环境（预部署，"Approval"）。他们测试并给予祝福（post-部署，"Validation"）。他们拒绝任何未通过 QA 的发布。
- Ops 安排产品发布。
如果这种情况不太可能发生，因为您知道在创建某个 "blessed" 构建之前，您的 none 版本是生产候选版本，那么将持续交付的目标阶段设置为 "Dev" -- 构建不会超出开发环境。当您准备好构建 QA 和生产候选对象时，请使用不同的目标阶段进行构建。
我已经开始深入研究 Release Manager。我见过的几乎（如果不是全部的话）示例都使用类似于 Dev -> Test -> Production 的发布路径。
假设我正在使用 Web 应用程序，而组织并没有真正使用持续集成。也许他们每天部署到 Dev 多次，每周测试几次，每月部署到 Production 一次。 （开发和测试实际上是不同的暂存环境。）
因此，使用 Dev -> Test -> Production 的发布路径，您将获得一大堆发布到 Dev，但您不希望所有 Dev 发布都进入测试。因此，在您准备好部署到测试之前，您将不得不拒绝大部分发布。
此处的最佳做法是什么？在您准备好 Test/Production 之前拒绝发布？创建多个发布路径，例如：
- 开发
- 开发 -> 测试
- 开发 -> 测试 -> 生产
...或其他？
在快乐的 DevOps/continuous 交付世界中，它的工作方式是这样的：
- 您可以随心所欲地向 Dev 推送位。选择构建以提升为 QA 的责任是开发人员的责任——他们应该拒绝他们知道不会有任何进展的版本。这是开发阶段的post-部署（"Validation"）步骤。
- QA 安排发布到他们的环境（预部署，"Approval"）。他们测试并给予祝福（post-部署，"Validation"）。他们拒绝任何未通过 QA 的发布。
- Ops 安排产品发布。
如果这种情况不太可能发生，因为您知道在创建某个 "blessed" 构建之前，您的 none 版本是生产候选版本，那么将持续交付的目标阶段设置为 "Dev" -- 构建不会超出开发环境。当您准备好构建 QA 和生产候选对象时，请使用不同的目标阶段进行构建。