让登台服务器与生产服务器相同的主要目的和意义是什么？
在我们公司，我们有临时服务器和生产服务器。我试图在最新版本发布后让它们处于 1:1 状态。我们已经在多个主机及其许多实例上运行了 Web 应用程序。
问题是，我主张在临时服务器和生产服务器上使用相同的 Web 应用程序架构（结构），以便轻松测试新功能并避免在新版本中创建新错误。
但并不是每个人都同意我的观点，对于他们来说，在暂存应用程序实例之间建立不同的连接并不是什么大问题。甚至可能在登台上比在生产服务器上拥有更多的应用程序和应用程序之间的连接。
我想问一下这种方法的优缺点？我的意思是一些好的观点同意我的观点，或者一些不好的观点，为什么我可能没有权利。后果的一些例子等等。
In our company we have staging and production servers. I'm trying to have them in state 1:1 after latest release. We've got web application running on several host and many instances of it.
The issue is that I am an advocate of having the same architecture (structure) of web applications on staging and production servers to easily test new features and avoid creating of new bugs with new releases.
But not everyone agree with me, and for them is not a such big deal to have different connection between staging application instances. Even maybe to have more application and connections between application on staging than on production server.
I would like to ask about pros and cons of such an approach? I mean some good points to agree with me, or some bad why maybe i don't have right. Some examples of consequences and so forth.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您的登台服务器与生产服务器有很大不同，那么在登台服务器上成功部署和测试不会告诉您当您最终部署到生产时世界是否会崩溃服务器。
我不认为你的同事所喜欢的混乱局面有任何真正的优势来弥补这个明显的劣势。他们声称，通过让登台服务器的配置与生产服务器的配置完全不同步，他们可以获得什么……？！
If your staging server is substantially different from your production server, then successful deployment and testing on the staging server does not tell you much about whether the world will come down crashing on you when you finally deploy to the production server.
I do not see any real advantage to your colleagues' preferred chaotic situation, to compensate for this obvious disadvantage. What do they claim they gain by letting the staging server's configuration get totally out of sync with that of the production server...?!
舞台布置就像部署的彩排。如果你穿的服装与当晚要穿的服装不同，你怎么知道它会合身，或者你不会被那些晃来晃去的东西绊倒。
更正式地说，您尝试使暂存环境尽可能接近生产环境，以尽量减少可能导致或隐藏部署中问题的差异。请注意，我说“尽可能接近”，因为并不总是可能拥有相同型号的磁盘或相同的网络互连，但您会尝试在可用资源内尽量减少这些事情。
Staging is like the dress rehearsal of deployment. If you're not wearing the same costume you will be wearing on the night, how do you know it's going to fit, or you're not going to trip over the dangly bits.
More formally, you try to keep the staging environment as close as possible to the production environment in order to minimize differences which may cause or hide issues in the deployment. Note that I say "close as possible", since it's not always possible to have the same model of disk, or the same network interconnects, but you try to minimize those things that you can within the resources you have available.
Martin Fowler 最近发表了博客，内容涉及可以从一个环境切换到另一个环境的相同环境，因此测试后，您的临时环境将成为您的生产环境。他说：
我认为这样的方法将是当今看似混乱的环境的一个很好的替代方案。祝你好运，说服你的团队！
Martin Fowler recently blogged about having identical environments that could be cut over from one to the other, so your staging environment becomes your production environment after testing. He says:
I think an approach like this would be a great alternative to the seemingly chaotic environment you have today. Good luck convincing your team!
正如 ptomli 所建议的那样，我也会采用“尽可能接近”的方法……这主要是由于成本因素。如果这是一个包含 5 台服务器的场，我绝不会建议只部署 1 台独立服务器。这对于涉及网络层的场景也很有帮助。如果存在由于任何原因（例如安全性！）而影响网络连接的补丁，则单机登台服务器可能无法反映补丁的“真正影响”。
I would go with "as close as possible" approach as well, as ptomli suggested... and that's mostly due to cost factor. If it is a farm that contains 5 servers, I would never recommend the staging to be just 1 stand alone server. This helps in scenarios where network layer is involved as well. If there are patches that affect network connectivity due to any reason (like security!) a single box staging server might not reflect the "real affect" of patching.