在什么时候应该切换到发布版本？

Jez Humble的“ 持续交付”中阐述的一种做法是，您应该构建一个软件包，然后将其发布到部署到的每个环境中，以便在投入生产之前，已经多次测试了部署和工件。

我完全支持这个想法。

另一方面，为您提供带行号的堆栈跟踪的调试模式构建在测试环境中非常有用，远程调试功能也是如此。但是，您想将发布版本发送到生产环境。

那么，对于遵循第一条原则的人们，您在什么时候从调试版本切换到发行版本？

是在第一次部署到测试环境之前，确定丢失调试模式的成本值得确保您尽早测试实际的候选发布版本吗？还是您在升级过程中的某个时候再次构建，以为您会信任构建过程而不是软件？还是只是将所有内容搞砸了，然后将调试版本部署到生产中？

注意：我知道这并不真正适用于解释语言，因为您通常可以在配置中轻按开关，而不是在构建时进行切换。

那么，对于遵循第一条原则的人们，您在什么时候从调试版本切换到发行版本？

当源代码获得版本号并将其推送到Debian构建队列中时，我们会尽早切换。但是，我们很幸运能够以指定的输入和输出以及很少的系统交互来制作科学的软件，因此重现错误情况的成本相当低。

这也是我的一般回答：更改版本的要点主要取决于错误的复制成本。如果这些都很高，我什至会提供调试版本来测试客户。尽管这可能会给生产版本带来构建失败的风险，但与花费数周的测试用例复制相比，这可能仍然便宜。

那么，对于遵循第一条原则的人们，您在什么时候从调试版本切换到发行版本？

一旦进入质量检查，我们就会切换到发行版本。但是，无论何时我们构建发行版，我们的构建过程也会构建dll的调试版本。这使我们能够快速将调试dll放入QA环境中，并在需要时获取其他信息。

dll的发行版和调试版都将备份并保存数年。

在我们的环境中，代码被部署在许多站点上。因此，应将不同的上下文应用于每个部署实例。通常，我们将其部署在关键的“风险较小”的地方，并查看经验。

此部署仍在生产中，因此，这不是“调试”模式。但是它也假设测试做得很好。

当然，在关闭调试模式的情况下，（在现场）快速调试代码可能很困难。但是，如果发行失败，则生产将切换回回退发行。

但是，我们尝试维护或创建一个相同的环境，该环境可以重现这种环境以再次进行测试。（我知道这并不总是一件容易的事），但是有时候我们需要做的只是复制交易/输入。

关键是，在调试中应该不会发布多少调试模式。虽然，我不会说这是规则。

另一件事是，该发行版仍被称为试用版，直到它已经确定（通过运行大量时间）其他场所尚未接受它为止。

还有其他一些实践可确保构建过程本身不会造成严重错误。请参见： 在RAD环境中提高发行质量的简单方法

我们已经设置了开发人员机器来构建调试版本。但是，一旦开发人员提交了代码，便会在我们的持续集成环境（TeamCity）中创建一个部署包，并将其发布。因此，每当我们决定部署到QA时，我们都会从CI服务器获取最新的部署程序包并将其推出，因此除非它在开发机器上，否则它将始终发布。

顺便说一句，对于某些语言，即使在构建发行版时，您仍然可以创建调试符号。例如，在.NET中，有一个“仅pdb”设置，该设置允许进行优化，但仍会创建调试文件。显然，针对发布版本进行调试比较棘手，因为它不是逐行等效的，但是在紧要关头仍然会有所帮助。