通常,我们会在生产服务器上安装 VS.NET,以便在必要时轻松解决产品问题。
这是个好主意还是坏主意?
通常,我们会在生产服务器上安装 VS.NET,以便在必要时轻松解决产品问题。
这是个好主意还是坏主意?
调试和开发应该在“安全”的环境中进行——这不是关键任务。例如,您应该有一个用于开发和调试的开发和/或 QA 服务器。
编辑: 您的 QA 服务器应该镜像您的生产服务器,以便您能够在与您的生产环境类似(如果不相同)的环境中进行调试。
这实际上取决于您是否接受安装带来的风险:
您还应该问自己,在没有 VS 的情况下在服务器上调试问题最困难的是什么:
这绝对不能接受。首先,对于调试,您始终可以使用 windows/windbg 的调试工具。也支持 .NET 调试(SOS / 罢工之子),并且使用备忘单并不难。Windbg 无需安装即可从 U 盘运行。
其次,也是最主要原因:每当您安装任何较新版本的 VS 时,它都会将其调试器注册为交互模式** - 当发生异常时,您会收到一个消息框。您需要手动编辑注册表以在安装后恢复为默认行为 - 没有人记得这一点。
不要这样做。有更好的方法来诊断问题。
推荐的方法是有一个生产服务器的镜像用于测试/调试目的。要使镜像保持最新,您需要同时在两台服务器上安装所有应用程序更新,并在每晚或按需在镜像上备份/恢复生产数据库。
仍然存在一些缺点,例如仅在重负载下才会发生的错误。在这种情况下,您需要某种日志记录来跟踪错误。此外,您可能需要购买额外的第三方组件许可证才能安装在生产镜像上。
我不认为这是一个好主意。您的代码应该有足够的日志记录,以便如果生产中出现问题,您可以查看日志并确定发生了什么并在开发环境中修复它,然后在推送到生产之前在暂存/uat 环境中对其进行测试。
在我工作的地方,不允许开发人员访问任何由服务器/网络团队处理的生产环境,但那是因为它是一项大型业务。对于较小的公司,开发人员可以访问,但这并不意味着您应该将其用于调试。
两个都。好处之一是它有时可以使诊断问题更容易。缺点之一是有时安装可能会破坏正在运行的 Web 应用程序。如果我不得不这样做,我只会这样做。
编辑:当同事决定在生产服务器上调试实时进程,在断点处停止应用程序,然后在没有意识到他已使应用程序不可用的情况下上床睡觉时,会发生另一个潜在的缺点。是的,这发生在我身上。
我永远不会直接在需要 Visual Studio 的生产服务器上做任何事情。对生产进行更改而不使其回到代码库并因此进入版本控制的风险太大。最终,您最终会重新引入一个您认为已经解决的错误,因为您只在生产服务器上更改了它。偶尔我会更新生产服务器上的标记或 XML 文件,但只有在开发中进行了更改并在 QA 机器上进行了测试之后,并且只有在不涉及实际代码的情况下。
当然,这取决于产品和您正在调试的内容。一般来说,您应该尽量避免它,但在某些情况下,您无法在测试服务器上完全复制场景,将调试器附加到正在运行的进程以快速缩小问题范围可能很有用。即,如果您正在运行 MMORPG 服务器,并且在某些负载条件下会出现间歇性错误,您可以花费数周或数月时间尝试从测试服务器上的日志文件和/或模拟连接中找出它,或者您可以附加在生产服务器上实时发生问题时使用调试器,并在一小时内解决。
不过,我倾向于将此视为一个例外情况,并尽可能合理地从生产服务器上进行调试。
取决于你如何使用它。它设计的大部分繁重的工作在生产服务器上都是不必要的。我通常在生产服务器上安装 Notepad++ 来编辑 xml、配置文件等。我会说如果你想安装 VS,那就去吧。
通常认为在生产服务器上安装 Visual Studio 不是“最佳实践”。这可能会带来安全风险——但我会担心的一个大问题是性能。Visual Studio 使用大量资源,在那里运行调试会显着影响生产应用程序的性能。