5

假设我设置了一个自动夜间构建。我应该保存哪些构建工件？

例如：

  • 输入源代码
  • 输出二进制文件

另外，我应该保存它们多长时间，在哪里保存？

如果我进行持续集成，你的答案会改变吗？

4

10 回答 10

17

你不应该为了保存而保存任何东西。您应该保存它，因为您需要它（即，QA 使用每晚构建来测试）。在这一点上，“保存多长时间”变成了 QA 希望它们多长时间。

我不会像标记/标记它那样“保存”源代码。我不知道您使用的是什么源代码控制，但对于任何质量源代码控制系统来说，标记都是微不足道的（性能和磁盘空间）。一旦您的构建被标记，除非您需要二进制文件，否则将它们放在身边并没有任何好处，因为您可以在必要时从源代码重新编译。

大多数 CI 工具允许您标记每个成功的构建。这对于某些系统来说可能会成为问题，因为您每天可以轻松拥有 100 多个标签。对于这种情况，我建议仍然运行每晚构建并且只标记它。

于 2008-10-23T17:24:45.513 回答
6

以下是我用于在每次构建时保留的一些工件/信息：

  • 您正在构建的快照的标记名称（在构建之前标记并进行干净的检查）
  • 构建脚本本身或其版本号（如果您将它们视为具有自己的版本控制的单独项目）
  • 构建脚本的输出：日志和最终产品
  • 您的环境快照：
    • 编译器版本
    • 构建工具版本
    • 库和 dll/libs 版本
    • 数据库版本（客户端和服务器）
    • IDE版本
    • 脚本解释器版本
    • 操作系统版本
    • 源代码控制版本（客户端和服务器）
    • 过程中使用的其他工具的版本以及可能影响构建产品内容的所有其他内容。我通常使用一个脚本来执行此操作，该脚本查询所有这些信息并将其记录到应该与其他构建工件一起存储的文本文件中。

问自己这个问题：“如果某些东西完全破坏了我的构建/开发环境，我需要什么信息来创建一个新环境，以便我可以重做我的构建 #6547 并最终得到与第一次完全相同的结果？”

你的答案是你应该在每次构建时保留的内容，它将是我已经提到的内容的子集或超集。

您可以将所有内容存储在 SCM 中（我建议使用单独的存储库），但在这种情况下，您应该将这些项目保留多长时间的问题失去意义。或者您应该将其存储到压缩文件夹或刻录带有构建结果和工件的 cd/dvd。无论您选择什么，都有一个备份副本。

只要您可能需要它们，就应该存储它们。多长时间，将取决于您的开发团队的步伐和您的发布周期。

不，如果您进行持续集成，我认为它不会改变。

于 2009-03-20T14:15:08.080 回答
5

这不是您问题的直接答案，但不要忘记对每晚构建设置本身进行版本控制。当项目结构发生变化时，您可能必须更改构建过程，这将从那时起破坏较旧的构建。

于 2008-10-30T01:55:42.227 回答
4

除了其他人提到的二进制文件之外，我还建议设置一个符号服务器和一个源服务器，并确保您从这些文件中获取正确的信息。它将极大地帮助调试。

于 2008-10-23T20:19:46.173 回答
3

我们保存二进制文件，剥离和未剥离（所以我们有完全相同的二进制文件，一次有调试符号，一次没有调试符号）。此外，我们将所有内容构建两次，一次启用调试输出，一次不启用（再次，剥离和未剥离，因此每次构建都会产生 4 个二进制文件）。构建根据 SVN 修订号存储到目录中。这样，我们就可以通过简单地检查这个版本来始终保留来自 SVN 存储库的源代码（这样源代码也被归档）。

于 2008-10-23T17:24:06.153 回答
3

我最近了解到的一个令人惊讶的问题：如果您处于可能被审计的环境中，您将希望保存构建的所有输出、脚本输出、编译器输出等。

这是您验证编译器设置、构建步骤等的唯一方法。

另外，保存多久，保存在哪里？

保存它们，直到你知道构建不会投入生产，只要你有编译的位。

保存它们的一个合乎逻辑的地方是您的 SCM 系统。另一种选择是使用会自动为您保存它们的工具，例如 AnthillPro 及其同类工具。

于 2009-03-15T16:10:31.823 回答
1

我们正在做一些接近“嵌入式”开发的事情，我可以告诉你我们节省了什么：

  • SVN 修订号和时间戳，以及它所构建的机器和由谁构建（也烧录到构建二进制文件中）
  • 完整的构建日志，显示它是否是完整/增量构建，任何有趣的 (STDERR) 输出生成的数据烘焙工具，编译的文件列表和任何编译器警告（这压缩得很好，是文本）
  • 实际的二进制文件（适用于 1-8 个构建配置）
  • 作为链接的副作用产生的文件：链接器命令文件、地址映射和一种“清单”文件，指示最终二进制文件中的内容（CRC 和每个文件的大小），以及调试数据库（.pdb相等的）

我们还将在“副作用”文件上运行一些工具的结果邮寄给感兴趣的用户。我们实际上并没有存档这些，因为我们可以稍后再复制它们，但这些报告包括：

  • 文件系统大小的总数和增量，按文件类型和/或目录细分
  • 代码段大小的总数和增量（.text、.data、.rodata、.bss、.sinit 等）

当我们运行单元测试或功能测试（例如冒烟测试）时，这些结果会显示在构建日志中。

我们还没有扔掉任何东西——考虑到，我们的目标构建通常最终每个配置大约 16 或 32 MiB，而且它们是相当可压缩的。

为了便于访问，我们确实将二进制文件的未压缩副本保留了 1 周；之后我们只保留轻微压缩的版本。大约每月一次，我们有一个脚本提取构建过程生成的每个 .zip，并将整个月的构建输出 7-zip 压缩在一起（这利用了每个构建只有很小的差异）。

每个项目平均每天可能有十几个或两个构建......构建服务器大约每 5 分钟唤醒一次，以检查相关差异和构建。一个非常活跃的大型项目一个月的完整 0.7z 可能是 7-10GiB，但它肯定是负担得起的。

在大多数情况下，我们已经能够以这种方式诊断一切。构建系统偶尔会出现问题，文件实际上并不是构建发生时应该是的版本，但日志中通常有足够的证据证明这一点。有时我们必须挖掘出一个能够理解调试数据库格式的工具，并为其提供一些地址来诊断崩溃（我们在产品中内置了自动堆栈转储）。但通常所有需要的信息都在那里。

值得一提的是，我们还没有破解 .7z 档案。但是我们那里有信息，我有一些关于如何从中挖掘有用数据的有趣想法。

于 2009-03-20T17:57:53.413 回答
1

保存不能轻易复制的东西。我在 FPGA 上工作，其中只有 FPGA 团队拥有工具，并且设计的一些内核（库）被许可仅在一台机器上编译。所以我们保存输出比特流。但是请尝试将它们相互检查，而不是使用日期/时间/版本标记。

于 2009-11-18T22:00:47.603 回答
0

另存为签入源代码控制或仅在磁盘上？什么都不保存到源代码控制。所有派生文件都应该在文件系统中可见并且可供开发人员使用。不要签入二进制文件、从 XML 文件生成的代码、消息摘要等。单独的打包步骤将使这些最终产品可用。由于您拥有更改编号，因此您始终可以在必要时重现构建，当然前提是您需要进行构建的所有内容都完全在树中，并且可通过同步对所有构建进行。

于 2008-10-23T17:28:35.100 回答
0

只要您构建的二进制文件有机会投入生产或被其他团队（如质量保证小组）使用，我就会保存它们。一旦某样东西离开生产，你用它做的事情可能会有很大的不同。对于很多团队来说，他们只会保留他们最近的先前构建（用于回滚），否则会丢弃他们的构建。

其他人则有监管要求，将任何投入生产的东西保存长达七年（银行）。如果您是一家产品公司，我会保留客户可能安装的任何二进制文件，以防技术支持人员想要安装相同的版本。

于 2008-11-18T15:35:20.323 回答