用于内部代码的神器存储库点

想象一下，基于云计算的解决方案中，部分代码的很大一部分是在内部开发的。我的问题是使用工件库作为内部代码的地步，您可以始终直接从源代码构建任何版本？用于内部代码的神器存储库点

换句话说，在构建服务器上花费时间以促进缓解pf从代码构建所需的构件版本vs添加像Nexus这样的构件库以将构建构件提供给部署？

来源

2012-12-11 iCode

在理论上是的，如果你可以是进入一个工件在这样的检查的来源一定

一切，数据文件
确切的环境中使用（操作系统，编译器，链接器，工具）内置你的神器可以完全恢复（虚拟机快照）
没有被遗忘

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

否则，您可能会遇到无法（完全）重建某个工件的情况。我宁愿将所有发布的内容都存储在安全的地方。

来源

2012-12-11 07:53:32

每次重建相同的修订版时，生成的文件都有不同的文件校验和。这使得不可能完全确定相同的修订已经部署到两台不同的机器上。重用工件存储库中的相同二进制文件解决了这个问题。其次，开源项目通常会发布一个包含源代码以及发布的工件的jar。这使第三方能够验证原始开发人员发布（和签名）的源代码和二进制文件。 –

的Continuous Delivery书呼吁建立一个二进制不止一次的反模式的做法：

此反模式违反了两个重要原则。首先是保持拆迁渠道的有效性，因此团队尽快得到反馈为。重新编译违反了这个原则，因为它需要时间，尤其是在大型系统中。第二个原则是总是建立在已知声音的基础上。这让部署到生产环境的二进制代码应为那些去通过验收测试过程中，确实在很多管道 IM-plementations，这是由存储散列的二进制文件在时检查完全一样的，他们在过程的每个后续阶段创建并验证二进制文件是否相同。

通过散列值进行二进制相等性检查对于高度管制域中的审计目的也很重要。

来源

2012-12-13 04:49:35 ottodidakt

用于内部代码的神器存储库点

回答

相关问题