The question about "What is an artifact repository?" contains an answer with an interesting explanation about the repository part of it. And from reading the entire answer, I am not sure what exactly an "artifact" means in the context of DevOps.
Any suggestions?
Ps: From one of the answers I seem to understand that maybe artefact is what I'm wondering (confused?) about ...
Wikipedia has a very good answer to this question. Artifact, sometimes also called Derived Object, is a product of some process applied to the Code Repository. Originally they were called Build Artifacts, but as more processes were applied other than build to create them, the first word was simply dropped.
The major distinction is that artifacts can be recreated from the code repository using the same process, providing you have preserved the environment in which the process was applied. As this process can be time consuming and the environment can be preserved imperfectly to be able to recreate the artifacts in the exact same way, we started to store them in Artifact Repositories.
Storing them apart from Code Repository in an Artifact Repository is a design decision a DevOps engineer would make. Some companies, namely Perforce, suggest to use their Code Repository as Artifact Repository as well. There are different requirements in terms of access, auditing, object sizes, object tagging and scalability on each repository and so depending on situation it is often better to use two distinct products. For example Git repositories are copied in their entirety to every development machine and so storing artifacts in the code repository would increase its size beyond all reason, although lately there are ways to mitigate this. Another decision to make is which artifacts to store. Some companies store even intermediate artifacts as individual object files, to speed re-builds, others store simply just the final binaries. Not all artifacts have the same value. Artifacts resulting from a release build could have different requirements than artifacts resulting from a developer build.
Most common artifacts are results of the following processes: Configuration, Preprocessing, Compilation, Linking, Automated Testing, Archiving, Packaging, Media files creation and processing, Data File Generation, Documentation Parsing, Code analyzing, QA, etc.
There are two usages of the word “artefact” and one makes source code an artefact while the second makes it not being an artefact: this can indeed be quite confusing!
“artefact” as a concrete thing, vs. an ideal thing – This meaning is the common meaning of the word “an object made by a human being, typically one of cultural or historical interest” and is not technical jargon. Here is an example in technical context: When you debug a software, you learn something about the software. It is often a valuable investment to turn this learning into a software artefact, like a regression test. Otherwise this learning will be forgotten and the the effort made to acquire it will be wasted. In this meaning, source code is considered an artefact.
“artefact” as something produced by a recipe – This meaning uses the popular image of the alchemist using some esoteric recipe to produce a magical device, often called an artefact. It is technical jargon used to distinguish between the source code, which corresponds to the recipe in the alchemist's metaphor, and anything derived from that source code, which corresponds to an artefact in the alchemist's metaphor. For instance I just automatised the artefact production for my plop-fizz program, now source tarballs, signature files, DEB and RPM packages can all be instantiated in just one command! This meaning does not recognise source code as an artefact, as the term is used to denote what is produced from this source code.
I suppose the answer may vary from place to place. Where I work at the moment an artifact is anything consumed by some other entity, except for the source code used for development - this goes into source control.
This includes binaries of the product or other needed products, libraries, object files, test artifacts like media files or test data.
Source code is not considered an artifact. Unless it matches the definition of "consumed by" - in our case including third party libraries, script code used for testing or other purposes (but not the development version itself).
Side note on the culture side. While in DevOps we consider the concept of "artifact repository" as a given situation, there seems to be not so much linkage to the organizational process.
Culture problem: if an organization uses ITIL, the certified people would say "we need to have a definitve media library, such a repository to place software configuration items we have produced". So people who care about well structured IT processes do not know which (not-management) tools support that and are in use. Vice versa, if you need a justification for a Nexus or Artifactory language, you might have hard times to explain it depending on the organization.
Further reading: https://en.wikipedia.org/wiki/Definitive_Media_Library
