What is an artifact repository? If it's just a place to store files, can't I just use a source control system?
2 Answers
During development you generate a fair amount of different artifacts. These might include:
- The source code
- The compiled application
- A deployable package
- Documentation
and potentially others as well
While you could use a source control system to store all of them, it's usually massively inefficient, as source control systems are usually designed to handle text based files, and not binary files. You might be able to use them as a simple storage mechanism, if most of your releases are text based, and you don't have to store a lot of binary data.
Artifact repositories however are designed to store all kinds of files, including binary ones. This includes anything from zipped up source codes, to build results, to things like docker images as well. Also, they usually not only store these artifacts but also help manage them using various additional functions, for example:
- Versioning support: properly store some metadata, like when each artifact was built, what their version number is, store their hashes, etc.
- Retention: make sure you only keep the important artifacts, and automatically delete ones that are only snapshots / not needed anymore, etc. based on various criteria you can set up
- Access control: set up who can publish and who can download the various artifacts
- Promotion: ability to promote artifacts. For example you can have snapshot artifacts with a short retention period on a server near your coders, and a separate repository near the live servers, where only artifacts that have been deemed deployable appear. This also includes support for various version channels, and moving artifacts between them (like promoting a specific version from beta to stable).
- Act as a native repository for the artifacts. Meaning you can use it as the main repository for maven, rubygems, docker, etc. This can also include caching of artifacts from the official repositories as well.
-
May worth adding the 'channel' capability over the Versionning support, having the ability to have some machine targeting the latest release in channel "develop" and prod machine targeting a specific version in channel "stable".– TensibaiCommented Mar 10, 2017 at 8:59
-
@Pierre.Vriens added some small comments, but maybe it can be addressed in a separate Question as well– SztupYCommented Mar 10, 2017 at 15:19
-
merci, but just in case, here is your chance to further address my additional comment ...– Pierre.Vriens ♦Commented Mar 10, 2017 at 15:39
-
Does it makes sense to also keep track of configuration files or fixtures in these kind of repositories?– tutucaCommented Nov 1, 2017 at 12:23
There's repository managers and Universal package repository managers (UPM).
UPM’s can store all your build artifact for Jenkins, teamcity etc. and can generally also act as repository mangers for many different types of binary artifacts Maven, npm, NuGet and more.
These would be tools like Jfrog Artifactory, Inedo ProGet, and Sonatype Nexus.
A pretty decent comparison is here: https://binary-repositories-comparison.github.io/