内部代码的工件库

时间:2012-12-11 06:25:00

标签: continuous-integration nexus artifactory continuous-deployment continuous-delivery

想象一下,基于云的解决方案,部署代码的很大一部分是在内部开发的。我的问题是在内部代码中使用工件存储库的意义何在,您可以直接从源代码构建任何版本?

换句话说,花时间在构建服务器上以便于从代码中构建所需的工件版本以及添加像Nexus这样的工件库来将构建工件提供给部署,这样做是否更有意义?

2 个答案:

答案 0 :(得分:2)

理论上是的,如果你可以肯定

  • 检查进入工件的所有内容,例如来源,数据文件
  • 用于构建工件的确切环境(操作系统,编译器,链接器,工具)可以完美恢复(虚拟机快照)
  • 没有遗忘

修改 在实践中,正如Mark O'Conner所指出的那样,即使这样,两个版本通常也不会完全相同,因为它们通常包含时间戳和校验和,具体取决于前者。你不得不以某种方式在构建过程中手动修复它们,或者以某种方式在构建计算机上精确地重现时间和时间。

否则,您可能会面临无法(完全)重建某个神器的情况。我希望将所有出版物存放在安全的地方。

答案 1 :(得分:1)

Continuous Delivery一书调用了反多次构建二进制文件的做法:

  

这种反模式违反了两个重要原则。首先是   保持部署管道的有效性,以便团队获得反馈   尽快。重新编译违反了这个原则,因为它   需要时间,特别是在大型系统中。第二个原则是   始终建立在已知声音的基础上。得到的二进制文件   部署到生产中的应该与生产的完全相同   通过验收测试过程 - 实际上在许多管道中   实现,这是通过存储二进制文件的哈希来检查的   创建它们的时间并验证二进制文件是否相同   在过程的每个后续阶段。

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