Should Artifactory NOT be used to capture the build artifacts that Jenkins produces?

Question

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.

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?

Answer 1

I don't think so. The following diagram comes from the sonatype website:

Demonstrates how your Maven repository manager can be a platform for your deployment processes

Answer 2

Artifactory (or any binary repository manager) SHOULD be used in conjunction with your CI server. There's even a plugin.

The reasons for maintaining a binary repository manager over other solutions (network share, SCM) are obvious:

1. Tailored for binaries.
2. Efficient.
3. Secure.
4. Single controllable gateway for distribution.

And many more.

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:

1. Binaries that build up your environment.
2. Binaries required by the build process.
3. Binaries produced during CI.
4. Binaries released that should be distributed.

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.