大多数公司在部署网站或软件时都会使用预生产环境，以便在向用户推出最新的变更之前对它们进行测试。虽然这样做带来了一些好处，比如增加了进一步发现问题和 Bug 的防御线，但也会增加成本和复杂性，并产生相反的效果。随着持续交付技术等技术的发展，团队借助这些技术手段确保软件总是可部署的，于是从复杂的分支结构和测试环境转移到更简单的基础设施的趋势开始形成。Squeaky是一家在不侵犯用户隐私的情况下帮助企业了解用户如何访问他们的网站或 Web 应用程序的公司，它采用了不一样的做法，并解释了为什么他们不使用 Staging 环境。他们相信这有助于他们更快地发布产品，并减少生产环境中的 Bug。
来自 Squeaky 的 Lewis Monteith 在一篇介绍公司部署方案的博文中详细描述了他们在 Staging 环境中发现的几个问题：
预发布环境永远无法与生产环境等同：生产环境中的云原生应用通常需要更多的资源来处理负载——但在预发布环境中配置与生产环境完全相同的资源，其成本令人难以承受。这将导致预发布环境配置漂移，架构规模缩减，有碍于在预发布环境测试中发现问题。
预发布请求不断进入队列，导致版本越来越多，削弱了所有权关系：如果多个开发人员或团队想要同时发布代码，预发布环境可能会成为瓶颈。等待会导致测试延迟，特别是如果测试失败，所有人都必须等待问题被修复。发布队列会导致分支分离，当有大量的变更需要合并时，这会给开发人员造成巨大的痛苦。
如果减少发布，将导致版本被捆绑在一起，这意味着每个版本将引入更多的错误，并且很难追踪问题是哪些变更以及是谁导致的，因为开发人员可能没有意识到变更已经进入到生产环境。
流程取代了责任：预发布环境通常由运维团队负责维护，因此部署到预发布环境意味着责任将从开发人员转移到了运维团队。
Squeaky 的方案旨在解决或避免这些问题——要做到这一点，涉及四个关键原则。
只合并准备发布的代码：这需要确保进行了适当的测试，并在开发中验证了所有变更。
扁平化的分支策略：所有的分支都是从主分支派生出来，变更只会从分支合并回主分支。开发人员需要在本地进行冒烟测试。
高风险变更需要进行特性标记：如果 Squeaky 比较关注高负载下的性能或用户可能对变更做出的反应，它就会使用特性标记来发布重大的变更。他们可以在单个用户的基础上做到这一点。
实践性的部署：通过监控、日志和警报来确保部署没有问题，Squeaky 还使用了蓝绿部署先，将向部分用户推出变更，直到确保一切正常。
Squeaky 放弃了 Staging 环境，转而遵循持续交付原则，这改变了人们对交付软件的看法。要移除正式发布之前的缓冲阶段，就需要提升变更的可靠性，而这反过来又降低了成本和复杂性，加快了开发速度。
作者简介：
Matt Saunders，我帮助团队使用 DevOps 流程和工具快速高效地交付高质量的软件。我有丰富的与复杂企业、小型初创企业以及介于两者之间的中型企业合作的经验，我与软件开发人员密切合作，确保快速、可靠地交付业务价值。我还管理着伦敦 DevOps 讨论小组，这个小组有超过 8000 名成员，每月举办一次非常受欢迎的行业活动。
原文链接：
How Removing Staging Environments Can Improve Your Deployments
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论