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

如果有方法犯错误,它最终会发生。大数定律。如果您也希望开发人员能够富有成效,那么将开发人员的负担推到完美上是不合理的。

• 变更管理
• 问责
• 质量保证
• 一键式构建/部署
• 单元测试
• 代码稳定性-假设您推送,对吧,当其他人刚签入代码时?

现在,管理费用/变更困难的数量应该直接与您的正常工作时间要求相关。重申:停机成本越高,您应该在预防停机方面投入越多。

一些人想到(可能与你的有重叠):

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

因为许多开发人员天生就不会认为他们犯了错误——同样的道理,优秀的开发人员团队有专门的测试团队。

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

我想,OOP开发人员应该理解职责分离。你打破它,你拥有它。与单独的运营团队一起避免问题。

在某些环境中(如金融),大量资金(有时还有法律)也面临着在不受控制的生产环境中,由于不明智或恶意的改变而带来的风险。

在小团队中,我可以看到有生产访问权的开发人员的情况,但必须控制和审计这一情况,以便您始终了解生产中的内容。从这个意义上讲,不管是谁按下部署和回滚按钮,它们都是存在的,并且是 只有 改变生产环境的方法。

我个人不希望这成为我工作的很大一部分。你可能会发现你自己的开发人员一旦看到他们可以花费更多的时间编码就同意了。

主要原因是,允许开发人员直接部署到生产环境中会切断质量保证过程。这会带来风险。哪些管理类型不喜欢。

所以对你来说另一个要点就是风险的大幅增加。

安全性—通过让一个网关管理员(带备份)只有一个人访问生产数据和服务器。这意味着更少的接入点。

易于管理-您不需要在生产环境中创建多个帐户来跟踪-甚至更糟的是,在多个帐户中共享一个帐户。(假设您的prod环境与您的dev环境分离。

熟能生巧——一个人只要养成习惯,坚持下去,就很少有机会搞砸事情。

通过直接部署到生产环境中,很有可能不涉及任何QA(即没有测试任何内容)。

因为需要有一个人知道站点上部署了什么。如果每个开发人员都可以部署,那么当有人发现错误时,您不知道谁部署了什么。

SOC-1合规性可能(不必要地)建议或要求开发人员是一个独立的人员,而不是部署到生产中的人员,以便控制措施到位以防止恶意意图。