continuous-integration - 内部代码的工件存储库点

Question

想象一下，对于基于云的解决方案，大部分已部署代码是在内部开发的。我的问题是，将 Artifact Repository 用于内部代码有什么意义，您总是可以直接从源代码构建任何版本？

换句话说，将时间花在构建服务器上以简化从代码构建所需的工件版本而不是添加像 Nexus 这样的工件存储库以将构建工件提供给部署不是更有意义吗？

Answer 1

理论上是的，如果你能确定的话

• 检查进入工件的所有内容，例如源、数据文件
• 可以完美还原用于构建工件的确切环境（操作系统、编译器、链接器、工具）（虚拟机快照）
• 什么都没有忘记

编辑 实际上，正如 Mark O'Conner 指出的那样，即使这样，两个构建通常也不会相同，因为它们通常包括时间戳和校验和，具体取决于前者。您将不得不在构建期间以某种方式手动修复这些问题，或者以某种方式在构建计算机上准确地重现时间和时间。

否则，您可能会面临无法（完全）重建某个 Artifact 的情况。我更喜欢将所有内容发布到安全的地方。

Answer 2

《持续交付》一书将多次构建二进制文件的做法称为反模式：

这种反模式违反了两个重要原则。首先是保持部署管道的效率，以便团队尽快获得反馈。重新编译违反了这一原则，因为它需要时间，尤其是在大型系统中。第二个原则是始终建立在已知健全的基础之上。部署到生产环境中的二进制文件应该与通过验收测试过程的二进制文件完全相同——事实上，在许多管道实现中，通过在创建二进制文件时存储二进制文件的哈希值并验证在该过程的每个后续阶段，二进制文件都是相同的。

通过哈希的二进制相等性检查对于高度监管域中的审计目的也可能很重要。