有什么理由不使用子域进行开发？

Question

我原本打算在我们的网络上使用本地计算机作为开发服务器。

然后我有了使用子域的想法。

因此，如果网站位于www.example.com，则可以在dev.example.com完成开发。

如果我这样做，我会知道整个软件堆栈的配置与开发和生产完全相同。此外，开发可以使用相同的数据库作为生产，消除了同步数据的麻烦。我甚至可以使用相同的媒体（图像，视频等）

我从来没有听说过其他人这样做过，所有这些专业人士都想知道为什么不呢？

这种方法的缺点是什么？

---

更新

好的，所以看起来这种方法的主要原因并不是使用相同的数据库来开发和生产。如果你把它排除在等式之外，它仍然是一个糟糕的主意吗？

Answer 1

显而易见的专业是你提到的：不需要复制文件，数据库甚至软件堆栈。显而易见的骗局稍微大一点：你使用完全相同的文件，数据库，甚至是软件堆栈。毋庸置疑：如果您的开发工作不正常（无限循环，等等），生产将与其一起被拉下来。显然，有可能在操作系统中监禁两个环境，但在这种情况下，你会回到原点。

我的建议：使用专用的开发机器而不是生产服务器进行开发。你想分开它以保持稳定。

PS：显然，如果开发环境错过了“WHERE id =？”，则会删除生产数据库中的所有信息。这听起来像个大问题，不是吗？ ：）

Answer 2

人们会这样做。

但是，针对生产数据库运行开发是一个坏主意 如果您的开发代码意外覆盖了某个字段，会发生什么？

Answer 3

我们按照您的建议使用生产域的子域进行开发，但是想到触摸prod数据库的开发代码有点令人毛骨悚然。

Answer 4

根据我的经验，使用相同的数据库进行生产和开发是不存在的。如何在不更改代码的情况下更改数据模型？ 还有两件事：

1. 明智地准备SQL脚本中的所有更改，这是在从不同的环境而不是您的控制台进行测试之后运行的。对现场系统进行的一些意外更新让我连续几周都处于领先地位。
2. 一旦发生在我身上，由于无序的查询结果，恢复的备份没有重现实时系统问题。这个奇怪的备份后来帮助我们找到真正的问题比在现场系统上重试更简单。

Answer 5

使用生产机器进行开发会削弱您的实验能力。在实时环境中尝试新模块/配置可能非常危险。如果我在apache conf中弄错了我们的dev机器，我会稍微给我的同伴们带来不便。当人们试图给你钱时，你将关闭现场服务器。

不仅如此，您还将与实时环境共享资源。当开发服务器还必须处理实际客户时，您可以忘记压力测试。任何可能导致开发服务器出现问题的错误（无限循环占用整个CPU，耗尽硬盘空间等）突然成为一个真正的问题。