提问人：tony 提问时间：11/16/2023 更新时间：11/17/2023 访问量：33
在客户计算机上添加更多调试
Adding more debugging on a customer machine
问：
寻找有关如何处理以下情况的建议：我们的一个客户有问题，但我们无法重现它。我们需要向他发送几个修改了更多调试信息的 DLL，以获取能够解决问题的数据。
我们的论点是：
- 我们不应该发布带有这些 DLL 的修补程序，而只是发送 文件（未版本控制），然后稍后发布带有修复程序的官方修补程序，并相应地对文件进行版本控制。结论：给他们未正确发布和版本控制的文件没什么大不了的
- 我们应该正式发布修补程序，仅包含调试信息，发送正确版本的文件。当我们有修复程序时，从发布分支回滚日志记录，并发布包含修复程序的修补程序。结论：使用正式版本做所有事情
答：
1赞
CAAHS
11/17/2023
#1
建议：
- 建立调试版本。这只是相同的修订版，但启用了调试符号和日志记录（这是一个功能标志，而不是功能分支 - 参见抽象分支）。
- 然后，支持人员可以随时掌握这些内容，以帮助了解客户在软件方面遇到的问题（现场调试）。
- 支持通道返回复制者所需的信息。
- 问题受让人重现。
- 问题被分派者添加回归测试。
- 构建并发布下一个增量。
- 然后，支持可以在没有调试信息的情况下进行下一个增量，并在客户端进行验证。
- 如果错误仍然存在，请在 2 处继续。只需使用下一个增量调试版本。
- 如果支持确认工作正常，请在问题中标记此项。
- 在客户确认工作后（如果不是更长的话，至少应该有一天），然后确认支持工程师确认工作。
案件已结案。弥补了自己构建管道中的差距（缺少调试构建，缺少回归测试），改进了流程，并为遇到软件问题的客户提供响应式支持，无论这是您的错还是他们的错。团队中没有关于任何不是手头问题的事情的不必要的讨论。
另一种解决方案是发布源代码和构建指令，然后让客户自己调试，并将反馈直接传递给开发部门。这取决于客户，并且似乎实际上不适用于您的情况，否则就不会讨论二进制构建工件以及如何混合和匹配这些东西。
一般来说，更好地确定开发过程中的实际问题（因为这是您可以控制的），而不是“解决方案”及其所有只能在布丁周围跳舞的“变体”。在客户享受支持的同时吃布丁。
评论