如何管理不同环境之间的发布版本？

译者 | 张健欣编辑 | 张婵网友在 reddit 上提问如何在开发、测试、预发布、性能测试、生产等不同环境中管理发布版本，得到了大家的留言和讨论

网友 argumentnull 在 reddit 上提出了这样一个问题：

在我的当前项目中，有一个一体化的 Web 应用程序，我们有这些环境——开发（dev）、测试（test）、预发布（staging）、性能测试（perf testing）和生产（production）环境。

我使用 Octopus deploy 来进行发布管理并推进从开发环境到测试环境的发布。以后，我还要署到其它环境并进行维护。我可以简单地将同一个发布版本推到其它环境，但是如果预发布环境需要发布一个缺陷修复，而预发布环境比开发环境落后几个发布版本，我就不得不在部署时手动选择包版本，因为部署工具通常选择较新的版本。

例如：Dev - v 0.9.166 Test - v 0.9.120 Staging- v0.7.34 Prod - 0.7.34

我在预发布环境做了一个缺陷修复，构建出来的包版本为 v0.7.35。现在，我必须记住这个版本并在要部署到预发布环境时手动选择这个版本。

你们是如何在项目中管理这些发布版本的呢？

有几位网友为他进行了解答。

网友 Tetha：

前些时候，我改变了自己在这方面的观念，因为我目前的工作有最少 3 个，事实上超过 6 个不同的产品环境。简直让人抓狂。

在你的案例中，有一组版本用于开发环境、一组较小的版本用于测试环境、一组更小的版本用于预发布环境以及最小的一组版本用于生产环境。在这种思维模式中，版本从开发环境开始，可能会向前移动，又或者不会。而且如果你在测试环境和预发布环境被打断了，事情就会变成一团糟，因为这些版本很难跟踪和记忆。

目前，我认为只有一种安全状态：所有的生产环境都位于最后的发布版本。如果生产环境在版本上滞后，你就处于一个糟糕的节点，因为它是不安全的、难以跟踪并且难以记住针对那个版本的所有部署步骤。生产环境滞后的版本越多，更新就越困难，那个环境的复杂度就会不断增长直到无法更新。每个单独的版本都应该部署到生产环境。开发环境、测试环境和预发布环境只是一些用一组测试来销毁坏版本的阶段，但是坏的版本应该被一个更好的版本快速替换，从而部署到生产环境。

因此，更新。更多地更新，更积极地更新。这样就可以消除问题。然后处理那些问题所导致的混乱。但是老实说，你最终还是要处理那些混乱。你要么处理 10 个小的混乱，要么处理一个相当巨大的混乱。

网友 atlgeek007

出现这种情况要么是发布得太慢了，要么是开发得太快了。我不确定为什么预发布环境和生产环境会比开发环境、测试环境落后那么多。

我注意到，你在开发环境有一个 0.9.166 版本，在测试环境有一个 0.9.120 版本——这里其实应该用一个“补丁”版本，如果你想要使用 semver 的话，你也许应该使用一个类似补丁的东西——

0.9.1.66 在开发环境
0.9.1.20 在测试环境

如果你真的想要使用 semver，这就更容易理解了，尽管 semver 在这点上已经失去了所有的意义。

网友 jkwysdom

在我看来，你做错了，你需要更快地部署版本，而且不应该落后超过一个 B 版本，如果 B 是在 A.B.C 中的话。因此，落后一个补丁版本是比较好的，因为那些版本时时更新，但是一个次要版本应该尽可能快地部署。你要么需要更慢的开发（大多数情况下不是一个好主意），要么需要更快的部署时间和测试。你每一步有自动化测试吗？如果没有，最好构建下。这样会加快部署时间并解决你的大部分问题。你真的需要梳理出这个烂摊子，因为你想想，当 CEO 说今天上线 1.2.3 版本，而你只测试到 1.1.1 版本的时候，会发生什么？明白我的意思了吗？自动化测试对于正确的生命周期和开发流程来说作用巨大。你这边听起来像是一个非常新的公司或项目，目前需要进行梳理。建议停止或放慢开发，投入测试。

网友 hatestreesap

我们没有单一的开发或测试环境，而是有多于 200-300 个环境，因此了解如何在每个环境中处理版本对于我们来说非常重要。我们采取的方案基本上是生产环境即真理。因此，每次提供一个新的环境，那个环境所选中的所有应用程序（我们在一个环境中会有多于 1000 个应用程序）会提供和生产环境一样的版本。如果某个特定应用程序的团队想要一个更加新的版本，可以直接到我们的 nexus 仓库，然后他们可以选择想要的版本。我们还提供一种可选方案，他们可以从 Jenkins 直接部署到各自的环境。生产环境即真理方案防止了脱离指定团队控制的破碎环境。

网友 alter3d

我有一个“promote”（推进）脚本。当我们推进到测试环境，这个脚本会抓取当前部署在开发环境的版本（在我们的这里，是 Docker 容器的版本），然后将这些版本部署到测试环境。当我们推进到预发布环境，它做的事情类似，不过是从测试环境抓取版本。当我们推进到生产环境，它抓取预发布环境的版本。

默认地，这个脚本差不多抓取任何东西（每个组件），但它理解“栈”的概念——一起开发和测试的逻辑上分组的组件。一个热修复（hotfix）通常会经过 dev->test->stage->prod 周期的推进，但是只针对那个栈。

我们有多个开发和测试环境，称为“通道”，进行不同的开发。其中一个通道用于长期功能工作，还有有一些通道用于各种原型工作等。只有一个通道有预发布环境和生产环境（当然，至少目前是这样），而且任何要发布到生产环境的东西都会合并到那个通道。

如果我们真的需要，这些脚本支持挑选一个单独的热修复组件，甚至跳过部署链中的环境，但是我们非常审慎地用这种方式。关键的利益相关者——开发领导 / 总监、DevOps 领导、QA 领导、业务经理——都需要参与决定任何产品的发布、热修复，而单独挑选出来的热修复会引起 DevOps 和 QA 的大量关注。

需要注意的关键点：

代码分支——特别是在管理发布分支方面的勤奋——是你的朋友。如果你遵循良好的 Git 代码分支与合并实践，你就已经做对了 90%。
代码分支不仅适用于实际产品代码库，还适用于你的 DevOps 构建 / 部署 / 管理脚本。
大量开发环境是你的朋友。每个主要功能都应该有一个开发环境。
上面这条要求非常好的自动化来快速搭建新的环境。
如果你是用不可变的基础设施（例如 Docker images、baked AMIs 等），这整件事就会变得非常非常简单。

你的项目中有多少个环境？你是怎么管理发布版本的呢？

你的鼓励让我更有动力

赞赏

0人进行了赞赏支持

你的鼓励让我更有动力

更多相关文章

随机推荐