发布版本与每晚版本

一个典型的解决方案是在构建服务器上运行CI（连续集成）构建：它将分析源代码，进行构建（在调试中）并运行测试，测量测试覆盖率等。

现在，另一种通常称为“夜间构建”的构建类型：做一些缓慢的工作，例如创建代码文档，制作安装程序包，部署到测试环境以及针对测试环境运行自动（烟熏或接受）测试等。

现在，问题是：

• 拥有第三个单独的“发布版本”作为发行版本更好吗？
• 还是在发布模式下“立即构建”并将其用作发布？

您在公司中使用什么？

（发行版本还应在潜在产品版本的源代码控制中添加某种标签。）

使发布版本等于夜间发布的一种情况是：您要测试与发布完全相同的内容。您不想发现生产中可能已经在开发测试中检测到的错误。

发行版和每晚构建之间的区别：

• 每晚构建会自动运行，嗯，每天晚上，而发布构建应在特定时间点手动运行
• 理想情况下，发布版本应标记/分支源代码，并可能在中央仓库中部署构建工件（例如，使用Maven时）

实际上，这些差异是我所知道的大多数构建管理系统中的一些其他选项。为了最大程度地减少人为错误的可能性，可以将这些错误保存在例如仅包含必要参数（并对其进行验证）的批处理/脚本文件中。

好吧，我希望发布构建尽可能接近每晚进行！理想情况下完全相同，但带有标签。

问题是，如果您的发布版本和夜间发布版本不相同，则任何不同之处都有可能掩盖问题（或使查找问题更加困难）。

我只有一个构建过程，它将构建CI服务运行的每个签入的所有内容。那将是调试和发布版本。

拥有两个或三个独立的过程只是要求它们开始随机更改而不被记录下来，不久以后人们就会发现自己必须为每个潜在的发布执行15个步骤才能使其准备就绪。

我热衷于做的一件事是将夜间构建置于发布模式而不是调试模式。使用log4net之类的日志记录框架替换System.Diagnostics.Debug，发布和调试模式之间的主要区别是对象生存期和代码优化。

除非您实际上打算将调试器附加到您的夜间构建中，否则我建议也这样做。

我们遵循的过程是每晚运行每晚运行一次，如果可以运行，那么我们可以将同一版本部署到我们的其他服务器上（无需重建，只需要打包的安装程序并运行它们即可）。如果我们对每夜构建有问题，那么我们会在分支上检查它的更改，并在白天在该分支上运行“每夜”构建。然后可以重新运行测试。