“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. In this meaning, source code is considered an artefact. Otherwise this learning will be forgotten and the the effort made to acquire it will be wasted. It is often a valuable investment to turn this learning into a software artefact, like a regression test. Here is an example in technical context: When you debug a software, you learn something about the software. 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. 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! 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. Artifacts resulting from a release build could have different requirements than artifacts resulting from a developer build. Some companies store even intermediate artifacts as individual object files, to speed re-builds, others store simply just the final binaries. Another decision to make is which artifacts to store. 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. 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. Some companies, namely Perforce, suggest to use their Code Repository as Artifact Repository as well. Storing them apart from Code Repository in an Artifact Repository is a design decision a DevOps engineer would make. 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. 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. Originally they were called Build Artifacts, but as more processes were applied other than build to create them, the first word was simply dropped. Artifact, sometimes also called Derived Object, is a product of some process applied to the Code Repository. Wikipedia has a very good answer to this question.
0 Comments
Leave a Reply. |