Development --> Staging --> Production
这是一个非常典型的工作流程。这很好。
“好吧,你想要一个‘Beta’环境来向一些还没有为黄金时段做好准备的用户/客户展示一些东西。”
Development --> Staging --> Beta
\-> Prod
“您说的‘前期制作’是什么意思?这就是准备阶段的用途。”
我见过一些(少数!)可能需要更多情况的情况,例如必须进行严格审计的行业,但即使这些情况似乎也失控了。(我曾经在一个有 11 个独立环境的地方工作过!)
还有人看到这种环境蔓延吗?我们如何管理那些认为这些“重要”的开发人员(和管理人员)?
甚至我关于增加成本和复杂性的请求似乎也被忽略了,感觉有些原因是懒惰。超过 4-5 个环境后,我的蜘蛛感应开始发麻……
答案1
有很多理由可以摆脱这种典型的工作流程。我们没有像 @CamelBlues 建议的那样的 QA 环境,毕竟代码在标记为完成并准备进入暂存阶段之前应该经过 QA。我们在开发时使用 QA,因此不需要 QA 环境。
无论哪种方式,代码的重大更改(例如 UI 替换或导致需要额外开发分支的事情)通常也需要与主开发环境不同的位置进行测试和阶段。
例如,如果我要替换 UI 并将应用程序移植到新的 MVC 系统,我可能会在源代码控制存储库中创建一个新分支来完成此操作。但是,我无法同时运行我的旧代码和新的 MVC 代码,因此我们需要一个新的环境来托管该分支,直到它完成。特别是如果您仍需要在此过程中修复错误。
请记住……这正是虚拟机的用途。您甚至可以使用 Microsoft 提供的 60-90 个试用许可证(如果这是您的平台)进行开发和测试。请求多少个环境实际上并不重要(在合理范围内并与您的团队规模相比),因为您应该有一个可以轻松快速地启动机器的平台,这就是大多数大型开发商店的运作方式,实际上允许开发人员和测试人员签出要使用的虚拟机。
更新:刚刚检查了我们的环境,我们也有预生产。发布和部署团队使用它来测试说明和修复,以便在实际接触生产箱之前进行试运行。为他们提供缓冲。
答案2
我不一定会将此称为“蔓延”,因为看起来你缺少 QA 环境。
开发 -> QA -> 准备 -> 生产
是您可以采用的另一种工作流程。
开发和 QA 可以是内部开发和管理环境,而 Staging 和 Production 可以是面向客户的。
[编辑]
您可能需要研究最多 4 个环境,并严格控制谁可以部署到哪个环境(以防止心脏病发作)。如果管理层开始要求提供 beta 或 pre-beta 等环境,请将它们发送到 QA 或 Staging 并告诉他们这是“beta”环境。
我认为锁定访问权限将有助于控制蔓延。如果您正在运行 CI 服务器,则可以通过在构建作业配置中放置密码字段并让构建脚本根据硬编码到脚本中的密码进行检查来限制部署到生产环境。即:
if [ $PASSWORD == 'foo' ]
build_app();
else
exit 1;
是的,这完全是黑客攻击和虚假安全,但它具有心理效应,可以阻止人们混乱地部署到生产环境中,而是留在最容易部署的环境中。