修补程序分支的单独环境？答案

【问题标题】：Separate environment for hotfixes branch?修补程序分支的单独环境？
【发布时间】：2018-05-29 07:16:50
【问题描述】：

目前我们转向了 gitflow 分支模型。我们为 QA 定义了 2 个环境：测试、登台。开发分支的代码部署到测试环境，/release 分支的代码部署到暂存环境。现在我们必须应用一个修补程序。所以我们从 master 创建了一个单独的 hotfix 分支，修复了 bug，然后......我们在哪里可以测试这个？我们应该有一个单独的 PreProduction 环境吗？我不确定我是否应该在 staging 上进行测试，因为在 staging 上我们可能有一个新版本正在测试中。

【问题讨论】：

标签： git testing qa git-flow test-environments

【解决方案1】：

QA 环境根本与分支无关。在理想情况下，每个版本（包括修补程序版本）都应经过所有 QA 阶段 - 测试、登台和生产。

【讨论】：

为什么称它为“包括修补程序发布”？修补程序与发布无关。为什么我应该在测试时测试我的修补程序，然后在进行生产之前在暂存时进行测试？
修补程序版本是与您的修补程序相关的版本。也许我对某些术语有误，但是如果您不打算发布修补程序，那么修补程序的原因是什么:) QA 工程师/开发人员应在进入下一个环境之前在所有环境中测试每个代码版本，并且与修补程序相同-您不需要不想直接推送它们，修补程序更改生产而无需测试。修补程序版本（无论您如何命名）应在测试中进行测试，然后再次测试并在暂存环境中被客户端接受，然后部署到生产环境（并再次测试）。
"然后在暂存环境中再次测试并被客户接受" - 我们不需要任何客户来验证代码，因为我们正在实施我们的产品，而不是针对特定客户的产品。跨度>
可以是客户、产品负责人、经理或任何负责反馈的人。如果您想在不阻止开发人员的情况下向任何人展示产品，则需要登台。开发人员在测试分支上工作，如果它变得稳定并经过测试，您将更改推送到登台。如果您不需要，那么为什么要定义登台测试环境？也许我误解了什么

【解决方案2】：

这是你应该做的。 1. 对于修补程序，在功能或除 QA 之外的任何其他分支中进行测试肯定很重要。 2. 测试此修补程序后，您可以转到 QA /staging 环境。在那里运行回归。

现在回到您的问题，为什么要在暂存原因中运行相同的测试 - 它会在通过运行完整的回归将修复部署到生产之前为您提供影响的完整图片。

当您将代码从专用基础架构较少的 QA 移至可能具有接近产品副本服务器等的 Staging 时，也有机会进行渗透/安全等级别的非功能测试..

希望这会有所帮助！

【讨论】：