不应使用Artifactory来捕获Jenkins生成的构建工件吗? [英] Should Artifactory NOT be used to capture the build artifacts that Jenkins produces?
问题描述
我们使用Jenkins来运行持续集成构建.这些构建的输出可能是EAR文件，WAR文件或TAR已部署到上游环境的文件集合.
We use Jenkins to run continuous integration builds. The output of these builds might be an EAR file, a WAR file, or a collection of files that are TAR'd up that get deployed to an upstream environment.
至此，我们已经使用Jenkins来管理产生的工件.但是，我们在内部部署了Artifactory.利用Artifactory捕获所产生的人工制品会是一个坏主意吗?如果是这样，为什么?例如，Artifactory是否仅打算持有可以在构建时通过Maven引入项目的版本的JAR，而不是要捕获持续集成工具使用的工件?
To this point we have used Jenkins to manage the produced artifacts. However, we have Artifactory deployed in-house. Would it be a bad idea to leverage Artifactory to capture the produced artifacts? If so, why? e.g is Artifactory only meant to hold JARs with versions that can be pulled into projects with Maven when building and not meant to capture artifacts that a continuous integration tool uses?
推荐答案
Artifactory(或任何二进制存储库管理器) SHOULD 可以与CI服务器一起使用. 甚至还有一个插件.
Artifactory (or any binary repository manager) SHOULD be used in conjunction with your CI server. There's even a plugin.
与其他解决方案(网络共享，SCM)相比，维护二进制存储库管理器的原因显而易见:
The reasons for maintaining a binary repository manager over other solutions (network share, SCM) are obvious:
- 针对二进制文件进行了量身定制.
- 高效.
- 安全.
- 用于分发的单个可控网关.
还有更多
因此，您使用二进制存储库管理器来控制依赖关系并解决工件，但是为什么要停在那里?您在整个周期中都有二进制文件:
So you use a binary repository manager to control your dependencies and resolve your artifacts, but why stop there? you've got binaries all over your cycle:
- 构建环境的二进制文件.
- 构建过程所需的二进制文件.
- CI期间产生的二进制文件.
- 发布的二进制文件应该分发.
二进制存储库管理器是最安全，最自然的存储方式.将所有二进制文件都保存在一个地方意味着减少了维护并提高了生成的可重复性.
A binary repository manager is the most safe, efficient and natural place to keep them. Maintaining all your binaries in one place means less maintenance and improved build reproducibility.
这篇关于不应使用Artifactory来捕获Jenkins生成的构建工件吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
