CODEWITHSUNDEEP
artifactoryshared-directorycontinuous-delivery
Med braim
Med braim

Reputation: 473

Why artifactory and not a shared folder?

Here is the situation, we have in the company a shared folder when we put the installer of an application (two files .sh one for bin and the other for conf) it's a manual action.

We are trying to make this action automatic from jenkins.

I have to give arguments: if we use artifactory to store data by sending data from jenkis with http request, what will be the plus? We can make automatic the action of putting data into our shared folder (if you can tell me more about the possibilities to make this last action, it will be great)

Any ideas?

Upvotes: 2

Views: 3524

Answers (1)

JBaruch
JBaruch

Reputation: 22893

There are tons of benefits in using a proper binary repository manager vs a shared drive. Here are just a few:

  • Smart storage. Artifactory uses a checksum-based storage, which is faster, more optimized and more versatile than a shared drive.
  • REST API. As you mentioned, you can put, search, retrieve and do much more with your artifacts using REST API
  • Permissions and promotions. With Artifactory you can have much more flexible permissions than with file system. For example, one can annotate artifacts with metadata (see next bullet), but can't deploy new artifacts. Once the permissions are in place for the repositories (who can access which repository), you can promote artifacts from one repository to another, exposing your artifacts to different groups. E.g. QA team can see the artifacts in the QA repository, but not in the dev repository. General audience can only see artifacts in release repository, etc.

  • Metadata. That's the king of arguments, and for me the most important difference between a dumb storage and Artifactory. You want to store as much information about your binaries as you can. Who built it? When it was built? Using what tool? What happened to this artifact? Did it pass QA? Why it is in a certain repository? Who moved it here? etc. Based on this metadata you can:

    • Make smart decisions about your binaries, e.g. which binary should be promoted to production
    • Trace any binary in any given time, to the build which produced it, to the source it was produced from and get all the information about it.

    Needless to say, all the manipulations on metadata (deploying files with it, setting it on existing files, retrieving it, searching the files by metadata, etc.) can be fully automated with REST API and with Artifactory Jenkins plugin.

I am with JFrog, the company behind Bintray and [artifactory], see my profile for details and links.

Upvotes: 9

Related Questions