为什么开发人员不能直接部署到生产环境？

Question

我一直在开发人员必须经历与网络运营（服务器人员）合作从开发/测试到生产部署的环境中工作。

我最近开始了一项工作，开发人员可以直接从他们的机器转到生产，没有中间人。是否有理由让开发人员无法做到这一点？

到目前为止我所拥有的：

• 您对部署更加谨慎 如果它必须通过的东西 其他人。作为一名年轻的程序员 它有时需要我多次尝试 得到一个有效的部署。以来 我学到了NetOps的家伙很生气 确保它是第一个是正确的 时间。

• 如果出现问题并且不止一个人知道发生了什么，那么就会有一些问责制。老板：“网站刚刚倒下了！”，办公室里的其他人都说：“安倍刚刚进行了部署，这是他的错！”

• 当某人独自负责生产服务器时，他们不太可能做些蠢事。

• 将（希望）有关部署和回滚功能的更多信息。可以回滚的日志，备份，自动功能......

还有其他正当理由吗？我只是一个控制狂吗？

Answer 1

一些想到的东西（可能与你的重叠）：

• 开发人员可以调整一些东西直到它工作。这不应该在生产中完成。如果该开发人员第二天被公共汽车撞到，那么没有人会知道该系统。记录和可重复的人员部署过程有助于确保捕获此类业务知识。
• 作为开发人员，我不想要那种访问权限。如果出现问题，那就不太可能是我的错。我会进来帮忙，毕竟我们都在同一个团队，但我想知道其他人必须审查我的工作并同意它。 （我的DB delta脚本也是如此。我想要一个更合格的DBA，他的全部责任是数据库来审查我的工作。如果他们所做的只是我告诉他们时告诉他们，那基本上没有什么不同给我直接访问。它只是慢了。）
• 开发人员经常快速修复简单的事情。我们都知道，它通常不像开发人员所想的那样干脆，而且快速解决方案要么没有修复它，要么破坏了其他东西。无论变更/修复多么小，都应该有质量保证流程。 （对于一些正常运行时间不那么关键的商店来说QA流程实际上可以是生产，但这是一个罕见的例外。从纯粹主义的角度来看，它不应该那样，但与任何事情一样，它是风险/回报率。如果风险很低（如果生产失败不会产生太大的惩罚，如果有的话），而且质量保证的成本相对较高，那就没关系了。）
• 监管需求。 PCI合规性等通常要求在作业之间明确分离任务。这经常被误解为“开发人员无法访问生产”并且处理得非常黑白。但它确实意味着开发人员应该只能访问他们所需要的工作。如果您不需要生产数据，并且该数据是敏感的，那么您就不应该拥有它。

Answer 2

因为许多开发人员先天无法认为他们会犯错误 - 这也是优秀开发团队拥有专门测试团队的原因。

“我只是在Prod中进行这个小配置更改，这不会破坏任何东西。”

我会想到，OOP开发人员应该理解职责分离。你打破它，拥有它。通过单独的Ops团队避免出现问题。

在某些环境（例如财务）中，大量资金（有时是法律）也会因不受控制的生产环境中的不明智或恶意变化而面临风险。

在小团队中，我可以看到开发人员拥有生产访问权限的案例，但必须对其进行控制和审核，以便您始终了解生产中的内容。从这个意义上说，推送部署和回滚按钮的人并不重要，但是它们存在并且是改变生产环境的唯一方式。

我不希望那是我工作的很大一部分。一旦他们看到他们花费更多时间进行编码，您可能会发现自己的开发者都同意。

Answer 3

主要原因是允许开发人员直接部署到生产环境会削减质量保证流程。这引入了风险。哪种管理类型不喜欢。

因此，另一个要点是风险大幅增加。

Answer 4

安全性 - 通过一个网守（带备份），只有一个人正在访问生产数据和服务器。这意味着更少的接入点。

易于管理 - 您无需在生产环境中创建任意数量的帐户来跟踪 - 或者更糟糕的是，在许多帐户中共享一个帐户。 （假设你的prod环境与你的开发环境分开。

实践是完美的 - 一个人制定一个例行公事并且坚持下去就会减少搞砸的机会。

Answer 5

如果有办法犯错，最终会发生。大数定律。如果你也希望它们具有生产力，那么把开发人员的负担变得完美是不合理的。

• 变更管理
• 问责
• QA
• 一键构建/部署
• 单元测试
• 代码稳定性 - 假设您推送，当其他人刚刚签入代码时？

现在，更改的开销/难度应与您的正常运行时间要求直接相关。重申：停机时间越长，就应该投入更多的时间来防止停机。

Answer 6

通过直接部署到生产环境，很可能不涉及任何质量保证（即没有测试任何内容）。

Answer 7

因为需要有一个人，你可以去了解谁在网站上部署了什么。如果每个开发人员都可以部署，那么当有人注意到错误时，你不知道是谁部署了什么。

Answer 8

SOC-1合规性可能（不必要地）建议或要求开发人员与部署到生产的人员分开，以便控制措施到位以防止恶意。