假设我设置了一个自动夜间构建。我应该保存构建的哪些工件？
例如：
- 输入源代码
- 输出二进制文件
此外，我应该保存它们多长时间，在哪里？
如果我做持续集成，你的答案会改变吗？
你不应该为了保存而保存任何东西。你应该保存它，因为你需要它（即QA使用夜间构建来测试）。在这一点上，"保存多长时间"变成了QA想要的多长时间。
我不会"保存"源代码，而是标记/标记它。我不知道你在使用什么源代码管理，但标记对于任何高质量的源代码管理系统来说都是微不足道的（性能和磁盘空间）。一旦您的构建被标记，除非您需要二进制文件，否则拥有它们真的没有任何好处，因为您可以在必要时从源代码重新编译。
大多数CI工具都允许您标记每个成功的构建。对于一些系统来说，这可能会成为问题，因为你每天可以轻松地拥有100多个标签。对于这种情况，我建议仍然运行夜间构建，并且只标记它。
以下是我在每次构建时都会保存的一些工件/信息：
- 您正在构建的快照的标记名称（在构建之前标记并执行干净的签出）
- 构建脚本本身或其版本号（如果您将它们视为具有自己版本控制的独立项目）
- 构建脚本的输出：日志和最终产品
- 环境快照：
- 编译器版本
- 生成工具版本
- 库和dll/libs版本
- 数据库版本（客户端和服务器）
- ide版本
- 脚本解释器版本
- 操作系统版本
- 源代码管理版本（客户端和服务器）
- 过程中使用的其他工具的版本以及可能影响构建产品内容的所有其他工具。我通常使用一个脚本来查询所有这些信息，并将其记录到一个文本文件中，该文件应该与其他构建工件一起存储
问问自己这个问题："如果有什么东西完全破坏了我的构建/开发环境，我需要什么信息来创建一个新的环境，这样我就可以重做我的构建#6547，并最终得到与第一次完全相同的结果？"
你的答案是你应该在每次构建时保留什么，它将是我已经提到的东西的子集或超集。
您可以将所有内容存储在SCM中（我建议使用单独的存储库），但在这种情况下，您应该将这些项目保存多久的问题就没有意义了。或者，您应该将它存储到压缩文件夹中，或者刻录一张带有构建结果和工件的cd/dvd。无论您选择什么，都要有一个备份副本。
你应该把它们储存到你可能需要的时候。多长时间，将取决于您的开发团队的速度和您的发布周期。
不，我认为如果你进行持续集成，它不会改变。
这不是您问题的直接答案，但不要忘记对夜间构建设置本身进行版本控制。当项目结构发生变化时，您可能需要更改构建过程，这将从那时起中断旧的构建。
我们保存二进制文件，剥离和取消剥离（因此我们有完全相同的二进制文件，一次有调试符号，一次没有调试符号）。此外，我们构建所有内容两次，一次启用调试输出，一次不启用调试输出（同样，剥离和取消剥离，因此每次构建都会产生4个二进制文件）。根据SVN修订号将构建存储到一个目录中。这样，我们就可以通过简单地签出这个修订版来始终保留SVN存储库中的源代码（这样也可以归档源代码）。
我最近了解到一个令人惊讶的问题：如果你所在的环境可能会被审计，你会想要保存构建的所有输出、脚本输出、编译器输出等。
这是您可以验证编译器设置、构建步骤等的唯一方法。
此外，保存多长时间，保存在哪里？
保存它们，直到你知道构建不会投入生产，只要你有编译的部分。
保存它们的一个合理位置是SCM系统。另一种选择是使用一个自动为您保存它们的工具，比如AnthillPro及其同类工具。
我们在这里做一些接近"嵌入式"开发的事情，我可以告诉你我们保存了什么：
- SVN修订号和时间戳，以及它是在哪台机器上构建的以及由谁构建的（也被烧录到构建二进制文件中）
- 一个完整的构建日志，显示它是否是一个完整/增量构建，任何有趣的（STDERR）输出，生成的数据烘焙工具，编译的文件列表和任何编译器警告（这压缩得很好，是文本）
- 实际的二进制文件（适用于1-8个构建配置中的任何一个）
- 作为链接的副作用生成的文件：链接器命令文件、地址映射和一种"清单"文件，指示烧入最终二进制文件的内容（每个二进制文件的CRC和大小），以及调试数据库（相当于.pdb）
我们还将通过"副作用"文件运行一些工具的结果邮寄给感兴趣的用户。我们实际上并没有存档这些，因为我们以后可以复制它们，但这些报告包括：
- 文件系统大小的总和和增量，按文件类型和/或目录细分
- 代码段大小的总和和增量（.text、.data、.rodata、.bss、.sinit等）
当我们运行单元测试或功能测试（例如烟雾测试）时，这些结果会显示在构建日志中。
我们还没有抛出任何东西——考虑到，我们的目标构建通常以每个配置约16或32 MiB结束，并且它们是相当可压缩的。
为了便于访问，我们确实将二进制文件的未压缩副本保存了一周；之后，我们只保留轻度压缩的版本。大约每月一次，我们有一个脚本，它提取构建过程产生的每个.zip，并将整个月的构建输出压缩到一起（这利用了每次构建只有很小差异的优势）。
平均每天每个项目可能有十几个或两个构建。。。构建服务器大约每5分钟唤醒一次，以检查相关差异和构建。一个非常活跃的大型项目一个月的完整.7z可能是7-10GiB，但它肯定是负担得起的。
在大多数情况下，我们已经能够通过这种方式诊断出所有问题。构建系统偶尔会出现问题，文件实际上并不是构建时应该有的修订版，但日志中通常有足够的证据表明这一点。有时，我们必须找到一个了解调试数据库格式的工具，并为其提供一些地址来诊断崩溃（我们在产品中内置了自动堆栈转储）。但通常所有需要的信息都在那里。
我们还没有破解过.7z的档案。但我们有这些信息，我对如何从中挖掘有用的数据有一些有趣的想法。
保存无法轻松复制的内容。我在FPGA上工作，那里只有FPGA团队拥有工具，设计的一些核心（库）只能在一台机器上编译。所以我们保存输出的比特流。但试着互相检查，而不是用日期/时间/版本戳。
是否保存为签入源代码控制还是仅保存在磁盘上？不为源代码管理保存任何内容。所有派生文件都应在文件系统中可见，并可供开发人员使用。不要签入二进制文件、从XML文件生成的代码、消息摘要等。单独的打包步骤将使这些最终产品可用。由于您有更改编号，如果需要，您可以随时复制构建，当然，假设构建所需的一切都完全在树中，并且可以通过同步对所有构建可用。
我会保存您构建的二进制文件，只要它们有机会投入生产或被其他团队（如QA小组）使用。一旦某个东西退出生产，你对它的处理方式可能会有很大的不同。对于许多团队来说，他们只保留最近的先前构建（用于回滚），否则就会放弃构建。
其他公司则有监管要求，将任何投入生产的产品保留长达七年（银行）。如果你是一家产品公司，我会保留客户可能安装的任何二进制文件，以防技术支持人员想要安装相同版本。