在生产服务器上开发

今天，我因在生产服务器上开发应用程序而大喊大叫。报价，“ 在生产服务器上发展是不能接受的-永远！ ”

这是情况。

1. 我建立了一个开发实例： http://example.com:3000
2. 生产实例为： http://example.com
3. 我完成了所有开发工作http://example.com:3000，当客户对更改感到满意时，我将其移至http://example.com。

我正在使用的应用程序是一个旧的Ruby on Rails应用程序，我不得不说一开始，我确实尝试在本地设置开发环境，但是我永远无法使其运行。经过一段时间的尝试，我放弃了并决定在生产服务器上进行开发。

再说一次，我是白痴吗？大概是这样，但是我从事Web开发已有两年了，而且从未遇到过这种情况。谁是正确的，为什么？

我曾经在生产服务器上进行开发。它可以正常工作，但是出于至少两个原因是不可取的：

1. 开发代码可能导致无限循环，内存泄漏或其他问题，从而锁定CPU，吞噬所有内存或以其他方式影响服务器，从而影响您的生产代码。
2. 如果您需要在开发工作中更改服务器环境的组件，例如Ruby或MySQL或其他版本，您将陷入困境。

正如其他人所述，在PROD环境中进行编码会使您的用户暴露于您的错误中。即使您启动了其他实例，您仍然可以获得共享的硬件资源，并且仍然可以访问生产文件和数据库。就像一些评论所指出的那样，如果您的Dev实例被黑客入侵（例如，因为您忘记擦除它，然后有人发现了Rails中的大量安全漏洞），那么您的应用程序就会运行在可公开访问的机器上作为门户。不幸的是。

不同的企业对此有不同的反应，但是通常可以将其分解为：

• 是否发生了乱糟糟的事情？
• 它需要多长时间恢复的变化（我主要用C ++的工作，所以回滚二进制可以显著比红宝石长，尤其是当你已经“丢失”的旧的二进制和必须重新编译）
• 什么变化的影响（粗略的指南：搞砸了存储的数据是如此糟糕得多比没有存储或显示数据，这又是不是完全无法显示该页面更糟）
• 如果您搞砸了然后走出了门，会有谁知道您做了什么？
• 是否有其他部署选项可以防止/最小化/检测到撞击之前的损坏？

这给您最终的计算：

• 这种完全可预防的破坏会给企业造成多少损失？

现在，这对于制定预算决策的人来说，整个管理结构的价值要低得多。因此大声疾呼。

如果您在公司内部的“关于我们”页面上打错字，然后键入自己的名字为L。如果您正在使用业务关键型购买应用程序，并且最终以纯文本形式意外调试了信用卡详细信息到主页...诉讼问题。在这些极端之间存在着一切，包括收费错误，生产力下降以及所有其他可能导致客户流失的事情。

即使在“关于我们”页面上也不允许这样做是因为直接在生产中进行编码会让人上瘾。您仅从为未成年人做起，但是随着时间的流逝，不必让DEV env陷入困境，这样会更快。

除此之外，业务规模可能会产生很大的影响。在两个人的团队中，当某物变脏时，您俯身肩膀，然后走开，“哦，笨蛋，放回去”。在拥有300名员工的公司中，您必须开始担心这是无能还是恶意，管理人员可能会对他们无法控制的事情负责。

归根结底，如果您按照程序操作并弄糟，他们会检查该程序出了什么问题。如果您规避程序并弄糟，即使责备有所蔓延，现在这也只是您的责任。是否要掷骰子取决于您。

我确实尝试在本地设置开发环境，但是我无法使其运行。经过一段时间的尝试，我放弃了并决定在生产服务器上进行开发。

我确实支持在生产服务器上进行AVOID开发的语句。如果这是配置文件中的错字更正并且由经理坚持，则可能只有在GUN下才有理由这样做。

WHY NOT?-因为这很冒险，以后很容易养成习惯，这会严重困扰您。因为致命的生产错误/故障可能会导致您被开除工作。

让我再次重申一下，即使您请求在production服务器上进行错字校正，也请先在上进行Staging。换句话说，请测试您的更改，进行测试，然后再进行测试，然后再投入生产。

这在“ 快速而肮脏 ”的文化似乎很普遍的地方经常发生。

编辑：在生产服务器上开发，因为单独的环境也不可接受。工作中引起的任何问题都可能会使生产服务器停机，并影响生产应用程序的性能。例如，我确实记得有一个安全漏洞的情况，当时我的前同事试图将生产服务器WinServer 2003用于开发目的。

这确实是协议问题。通常，这不是您要执行的操作。您希望不考虑生产机器。它们可能包含敏感数据，并且您不想使用非生产就绪代码来损害生产站点的性能或稳定性。

就是说，有些时候通常会这样做。如果您处在流量低的Brouchureware或简单CMS站点抽水的位置，那么问题就不大了。但是，如果您正在处理具有敏感数据或“关键业务”流程的任何事物，那么您实际上不应该冒着在同一台计算机上使用开发代码的风险。

不直接在生产环境中进行开发的另一个重要原因是，开发实例通常会产生并显示冗长的错误和堆栈跟踪。您永远不想将其公开给用户。

是的，您可以记录它们而不是将它们显示给客户端，但是这使得调试比以前要有趣得多。

添加解决了您的开发实例遇到麻烦的另一问题：部署基于VirtualBox的VM 取得了巨大的成功，该VM与Ubuntu Server复制了我们的生产环境（当然不包括硬件）。

我非常惊讶，没有人提到最重要的原因，为什么绝对禁止在生产服务器上进行开发：

不要搞乱生产数据，这很容易发生！

一个地方的微小错误会导致其他计算出现巨大麻烦，然后在第二天，所有数据都是垃圾，客户很生气。这比UI中的错误或在这里到那里的崩溃小得多，而且要糟得多。

对于大多数应用程序，该值位于数据中，而不是例程中。

我总是尝试问其他开发人员针对特定公司的程序。通常是的，您应该始终：

1. 在本地构建。
2. 将其推入尽可能模仿生产的某种类型的盒子，以查看其是否在此处效果良好。
3. 可能将其推送到质量检查或认证实例，以传递给客户/质量检查团队以检查更改。
4. 推向生产。

您可以将Capistrano食谱与GitHub搭配使用来为您处理所有这些事情。如果您每次必须手动执行此操作，它可能会很快变旧。

在产品上进行开发的另一个问题是，有时这些东西在源代码管理中会丢失，将来的发行版可能会撤消您的快速修复更改。

如果您在美国的一家上市公司中，出于监管原因，您甚至都无法获得产品。通常，在任何公司中，开发人员都不能访问产品（出于所有答案中提到的观点以及可能的法律原因），因此，您的经理在允许您使用该服务器的权限方面也是错误的。

使用“总是”或“从不”的规则通常是错误的。在某些情况下，打破最佳实践是合理的。更好的建议是“除非有充分的理由，否则不要接触生产服务器”

在我的职业生涯中，我发现只有两个原因可以更改生产服务器上的代码：

1. 仅在此处发生且无法在开发环境中再现的错误或行为。这些很少见，但可能非常烦人并且很难找到。

2. 直接修复一些关键错误，如果花费几分钟以上，您将迫不及待地等待通过正常部署过程。此后已与管理人员清除。如果幸运的话，整个职业生涯中应该只有很少的那一部分。

最好将两者都留给熟悉系统的高级开发人员。