<p>Wikipedia has a very good answer to this question. <a href="https://en.wikipedia.org/wiki/Artifact_(software_development)" rel="noreferrer">Artifact</a>, sometimes also called <a href="https://en.wikipedia.org/wiki/Derived_object" rel="noreferrer">Derived Object</a>, is a product of some <em>process applied</em> to the <strong>Code Repository</strong>. Originally they were called <strong>Build Artifacts</strong>, but as more processes were applied other than build to create them, the first word was simply dropped.</p>

<p>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 <strong>Artifact Repositories</strong>.</p>

<p>Storing them apart from <strong>Code Repository</strong> in an <strong>Artifact Repository</strong> is a design decision a DevOps engineer would make. Some companies, namely <a href="https://www.perforce.com/helix" rel="noreferrer">Perforce</a>, <a href="https://www.slideshare.net/perforce/how-to-combine-artifacts-and-source-in-a-single-server" rel="noreferrer">suggest</a> to use their Code Repository as Artifact Repository as well. There are different requirements in terms of <em>access</em>, <em>auditing</em>, <em>object sizes</em>, <em>object tagging</em> and <em>scalability</em> on each repository and so depending on situation it is often better to use two distinct products. For example <a href="https://git-scm.com" rel="noreferrer">Git</a> 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.</p>

<p>Most common artifacts are results of the following processes: <strong>Configuration</strong>, <strong>Preprocessing</strong>, <strong>Compilation</strong>, <strong>Linking</strong>, <strong>Automated Testing</strong>, <strong>Archiving</strong>, <strong>Packaging</strong>, <strong>Media files creation and processing</strong>, <strong>Data File Generation</strong>, <strong>Documentation Parsing</strong>, <strong>Code analyzing</strong>, <strong>QA</strong>, etc.</p>

CC BY-SA 3.0
2017-03-10T16:20:40.000Z
The sentence about git size is not totally exact, using [git lfs](https://git-lfs.github.com/) you can mitigate this issue. (just a small precision)
Tensibai
CC BY-SA 3.0
2017-03-10T16:24:13.817Z
Interesting, that even confirms my thinking (guessing) even more. 2 things: your perforce-link needs fixing and extra question: would you agree that "keeping track of your test data" (the input you used, and the output you got) could be considered as such artifacts also? And BTW, this answer reminds me about "verification levels" used in the area of "software escrow" (if you're familiar with that). I start to wonder of software escrow topics should be considered as on topic for DevOps ... Maybe @Tensibai might want to comment on that also?
Pierre.Vriens
CC BY-SA 3.0
2017-03-10T16:26:58.660Z
@Pierre.Vriens for your test datas, that's hard to day, if your tests data are a DB, that doesn't fitting an artifact notion. For escrow, I've no idea as is, if the questions are focused enough that sounds ok to me.
Tensibai
CC BY-SA 3.0
2017-03-10T16:34:48.673Z
@Pierre.Vriens I mean there's so much things fitting the name 'test datas' (from simple number to millions files via sample DB records) that it's too broad without context.
Tensibai
CC BY-SA 3.0
2017-03-10T16:36:32.373Z
@Pierre.Vriens (and sorry Jiri for the notifications) I don't think the contractual negotiations with your provider are on topic, and what you describe is just legal negotiation for what I guess.
Tensibai
CC BY-SA 3.0
2017-03-10T16:50:12.440Z
Tests can result are often log files, which are artifacts. To be honest you can use DB as artifact repository. Oracle RDBMS has some blob, clob and other features that could make it better than most artifactories for this and there is even NFSv4 seever to serve data as FS out of it. But even if you have DB of results of tests, you can sort of look at it as a kind of artifact repository. Although it is usually taken as separate type of data.
Jiri Klouda
CC BY-SA 3.0
2017-03-16T17:10:27.010Z
"from following processes.... , etc." => what are other examples of the processes?
Ta Mu
CC BY-SA 3.0
2017-03-16T22:16:41.303Z
I list a whole bunch of them at the end of the answer in bold letters...
Jiri Klouda
CC BY-SA 3.0
2017-03-10T16:15:26.610Z
2017-03-10T16:52:06.090Z
2017-03-10T16:52:06.090Z
Jiri Klouda
<p>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.</p>

<p>This includes binaries of the product or other needed products, libraries, object files, test artifacts like media files or test data.</p>

<p>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).</p>

CC BY-SA 3.0
2017-03-10T15:58:38.970Z
Hm, interesting, you're confirming what I was guessing. Would you agree that it doesn't really matter which platform or OS we're talking about. For example, even for mainframes one "might" use this terminology also ... If so, can you also include something about that in your answer please?
Pierre.Vriens
CC BY-SA 3.0
2017-03-10T16:07:24.417Z
Even actual code from the version control can/should be considered an artifact if it's consumed. For example template-based HTML pages to be deployed as-is on a website. They are deployment artifacts, which may need to be explicitly copied together with other built artifacts in some temporary location for the actual deployment, for example. But it *might* not make a lot of sense to store them in an artifact repository since they can always be obtained from the source code repository.
Dan Cornilescu
CC BY-SA 3.0
2017-03-11T07:01:05.133Z
@Pierre Confirming that which OS is orthogonal to being an artifact, I'm not sure why it should be included in the answer a lot of other things are irrelevant as well.
Rsf
CC BY-SA 3.0
2017-03-10T15:48:32.557Z
2017-03-10T15:57:00.647Z
2017-03-10T15:57:00.647Z
Rsf
<p>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!</p>

<p><strong>“artefact” as a concrete thing, vs. an ideal thing</strong> – 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: <em>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.</em> In this meaning, source code is considered an artefact.</p>

<p><strong>“artefact” as something produced by a recipe</strong> – 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 <em>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!</em>  This meaning does not recognise source code as an artefact, as the term is used to denote what is produced from this source code.</p>

CC BY-SA 3.0
2017-03-10T16:30:34.853Z
2017-03-10T16:30:34.853Z
Michaël Le Barbier
<p>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.  </p>

<p>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.</p>

<p>Further reading:
<a href="https://en.wikipedia.org/wiki/Definitive_Media_Library" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Definitive_Media_Library</a></p>

CC BY-SA 3.0
2017-03-15T19:36:23.970Z
Hi. Welcome to the site. Please add more info to the answer. In it's current state, it's link-only, and will be flagged :)
Dawny33
CC BY-SA 3.0
2017-03-16T16:58:58.443Z
if DevOps is also about culture, I think a link to ITIL important because sometimes it rules the IT organization at a higher organizational level. Added more explanation to clarify this symmetry of ignorance.
Ta Mu
CC BY-SA 3.0
2017-03-16T17:06:31.433Z
I don't think it really address the question of what is an artefact, but at least it looks like an honest attempt to answer now.
Tensibai
CC BY-SA 3.0
2017-03-16T19:17:48.727Z
I agree with @Tensibai (now), and deleted my prior comment (no longer suspecious). And even though everything in this answer does makes sense, I still don't get it how this "Side note"-answer addresses my question, which I tried to summarize in my question title also, i.e. "***What is an artifact (or artefact)?***". I welcome new attempts, OK?
Pierre.Vriens
CC BY-SA 3.0
2017-03-15T19:30:32.053Z
2017-03-16T16:57:35.140Z
2017-03-16T16:57:35.140Z
Ta Mu
<p>The question about "<a href="https://devops.stackexchange.com/q/452/40">What is an artifact repository?</a>" contains an answer with an <a href="https://devops.stackexchange.com/a/453/40">interesting explanation</a> about the repository part of it.
And from reading the entire answer, I am not sure what exactly an "<em>artifact</em>" means in the context of DevOps.</p>

<p>Any suggestions?</p>

<p>Ps: From one of the answers I seem to understand that maybe <strong>artefact</strong> is what I'm wondering (confused?) about ...</p>

CC BY-SA 3.0
2017-03-13T07:57:32.467Z
Our friends of English SE have written a view on "artifact" vs. "artefact": http://english.stackexchange.com/questions/37903/difference-between-artifact-and-artefact
7ochem
<terminology><artifacts>
What is an artifact (or artefact)?
Pierre.Vriens
# What is an artifact (or artefact)?

(Asked by: username_0 on 2017-03-10)

The question about "[What is an artifact repository?](https://devops.stackexchange.com/q/452/40)" contains an answer with an [interesting explanation](https://devops.stackexchange.com/a/453/40) 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 ...

**Tags:** terminology, artifacts

> **Comments:**
> **username_1**: Our friends of English SE have written a view on "artifact" vs. "artefact": http://english.stackexchange.com/questions/37903/difference-between-artifact-and-artefact  

---

## 4 answers

### Answer by username_2 on 2017-03-10. Score: 29 | Accepted answer

Wikipedia has a very good answer to this question. [Artifact](https://en.wikipedia.org/wiki/Artifact_(software_development)), sometimes also called [Derived Object](https://en.wikipedia.org/wiki/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](https://www.perforce.com/helix), [suggest](https://www.slideshare.net/perforce/how-to-combine-artifacts-and-source-in-a-single-server) 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](https://git-scm.com) 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.

> **Comments:**
> **username_3**: The sentence about git size is not totally exact, using [git lfs](https://git-lfs.github.com/) you can mitigate this issue. (just a small precision)  
> **username_0**: Interesting, that even confirms my thinking (guessing) even more. 2 things: your perforce-link needs fixing and extra question: would you agree that "keeping track of your test data" (the input you used, and the output you got) could be considered as such artifacts also? And BTW, this answer reminds me about "verification levels" used in the area of "software escrow" (if you're familiar with that). I start to wonder of software escrow topics should be considered as on topic for DevOps ... Maybe @username_3 might want to comment on that also?  
> **username_3**: @username_0 for your test datas, that's hard to day, if your tests data are a DB, that doesn't fitting an artifact notion. For escrow, I've no idea as is, if the questions are focused enough that sounds ok to me.  
> **username_3**: @username_0 I mean there's so much things fitting the name 'test datas' (from simple number to millions files via sample DB records) that it's too broad without context.  
> **username_3**: @username_0 (and sorry Jiri for the notifications) I don't think the contractual negotiations with your provider are on topic, and what you describe is just legal negotiation for what I guess.  
> **username_2**: Tests can result are often log files, which are artifacts. To be honest you can use DB as artifact repository. Oracle RDBMS has some blob, clob and other features that could make it better than most artifactories for this and there is even NFSv4 seever to serve data as FS out of it. But even if you have DB of results of tests, you can sort of look at it as a kind of artifact repository. Although it is usually taken as separate type of data.  
> **username_4**: "from following processes.... , etc." => what are other examples of the processes?  
> **username_2**: I list a whole bunch of them at the end of the answer in bold letters...  

---

### Answer by username_7 on 2017-03-10. Score: 8

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.


---

### Answer by username_5 on 2017-03-10. Score: 3

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).

> **Comments:**
> **username_0**: Hm, interesting, you're confirming what I was guessing. Would you agree that it doesn't really matter which platform or OS we're talking about. For example, even for mainframes one "might" use this terminology also ... If so, can you also include something about that in your answer please?  
> **username_6**: Even actual code from the version control can/should be considered an artifact if it's consumed. For example template-based HTML pages to be deployed as-is on a website. They are deployment artifacts, which may need to be explicitly copied together with other built artifacts in some temporary location for the actual deployment, for example. But it *might* not make a lot of sense to store them in an artifact repository since they can always be obtained from the source code repository.  
> **username_5**: @Pierre Confirming that which OS is orthogonal to being an artifact, I'm not sure why it should be included in the answer a lot of other things are irrelevant as well.  

---

### Answer by username_4 on 2017-03-15. Score: 1

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>

> **Comments:**
> **username_8**: Hi. Welcome to the site. Please add more info to the answer. In it's current state, it's link-only, and will be flagged :)  
> **username_4**: if DevOps is also about culture, I think a link to ITIL important because sometimes it rules the IT organization at a higher organizational level. Added more explanation to clarify this symmetry of ignorance.  
> **username_3**: I don't think it really address the question of what is an artefact, but at least it looks like an honest attempt to answer now.  
> **username_0**: I agree with @username_3 (now), and deleted my prior comment (no longer suspecious). And even though everything in this answer does makes sense, I still don't get it how this "Side note"-answer addresses my question, which I tried to summarize in my question title also, i.e. "***What is an artifact (or artefact)?***". I welcome new attempts, OK?  

---

