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

Question

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

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

到目前为止我所拥有的:

• 如果必须通过其他人,你会更加小心部署某些东西.作为一名年轻的程序员,它有时需要多次尝试才能完成工作部署.由于NetOps的家伙很生气,我学会了第一次确保它是正确的.

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

• 有些人唯一的责任是生产服务器,它们不太可能做一些愚蠢的事情.

• (希望)有关于部署和回滚功能的更多信息.日志,可以回滚的备份,自动功能......

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

Answer 1

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

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

Answer 2

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

"我只是在Prod中进行这个小配置更改,这不会破坏任何东西."

我想,OOP开发人员应该理解职责分离.你打破它,拥有它.避免单独的Ops团队的问题.

在某些环境(例如财务)中,大量资金(有时是法律)也会受到不受控制的生产环境中的不明智或恶意变更的风险.

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

我一个人不希望这是我工作的很大一部分.一旦他们看到他们可以花多少时间来编码,你可能会发现你自己的开发者都同意.

Answer 3

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

因此,另一个要点是风险大幅增加.

Answer 4

安全性 - 有一个看门人(有备份)只有一个人访问生产数据和服务器.这意味着更少的接入点.

易于管理的 - 你不必在生产环境中创建多个帐户跟踪 - 在许多甚至更糟糕,共享一个帐户.(假设您的prod环境与您的开发环境分开.

实践是完美的 - 一个人建立一个例行公事并坚持下去,减少了搞砸的机会.

Answer 5

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

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

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