Qu'est-ce qu'un artefact (ou artefact)?

La question sur " Qu'est-ce qu'un référentiel d'artefacts? " Contient une réponse avec une explication intéressante sur la partie du référentiel. Et à la lecture de la réponse complète, je ne sais pas exactement ce que signifie exactement un « artefact » dans le contexte de DevOps.

Aucune suggestion?

Ps: D'après l'une des réponses, je semble comprendre que peut-être l' artefact est ce que je me demande (confus?) À propos de ...

Wikipedia a une très bonne réponse à cette question. L'artefact , parfois également appelé objet dérivé , est le produit d'un processus appliqué au référentiel de code . À l'origine, ils s'appelaient Build Artifacts , mais comme plus de processus étaient appliqués que la construction pour les créer, le premier mot a simplement été abandonné.

La principale différence est que les artefacts peuvent être recréés à partir du référentiel de code en utilisant le même processus, à condition que vous ayez préservé l'environnement dans lequel le processus a été appliqué. Comme ce processus peut prendre du temps et que l'environnement peut être imparfaitement préservé pour pouvoir recréer les artefacts de la même manière, nous avons commencé à les stocker dans les référentiels d'artefacts .

Les stocker en dehors du référentiel de code dans un référentiel d'artefacts est une décision de conception qu'un ingénieur DevOps prendrait. Certaines entreprises, à savoir Perforce , suggèrent également d'utiliser leur référentiel de code comme référentiel d'artefacts. Il existe différentes exigences en termes d' accès , d' audit , la taille des objets , le marquage d'objets et l' évolutivité de chaque référentiel et donc en fonction de la situation , il est souvent préférable d'utiliser deux produits distincts. Par exemple Gitles référentiels sont copiés dans leur intégralité sur chaque machine de développement et donc le stockage des artefacts dans le référentiel de code augmenterait sa taille au-delà de toute raison, bien qu'il existe récemment des moyens pour atténuer cela. Une autre décision à prendre est celle des artefacts à stocker. Certaines entreprises stockent même des artefacts intermédiaires sous forme de fichiers d'objets individuels, pour accélérer les reconstructions, d'autres ne stockent que les binaires finaux. Tous les artefacts n'ont pas la même valeur. Les artefacts résultant d'une build de version peuvent avoir des exigences différentes de celles des artefacts résultant d'une build de développeur.

Les artefacts les plus courants sont les résultats des processus suivants: configuration , prétraitement , compilation , liaison , tests automatisés , archivage , conditionnement , création et traitement de fichiers multimédias , génération de fichiers de données , analyse de la documentation , analyse de code , assurance qualité , etc.

Il y a deux usages du mot «artefact» et l'un fait du code source un artefact tandis que le second fait qu'il n'est pas un artefact: cela peut en effet être assez déroutant!

«Artefact» en tant que chose concrète, par opposition à une chose idéale - Cette signification est la signification courante du mot «un objet fabriqué par un être humain, généralement d'intérêt culturel ou historique» et n'est pas du jargon technique. Voici un exemple dans un contexte technique: lorsque vous déboguez un logiciel, vous apprenez quelque chose sur le logiciel. C'est souvent un investissement précieux que de transformer cet apprentissage en un artefact logiciel, comme un test de régression. Sinon, cet apprentissage sera oublié et l'effort consenti pour l'acquérir sera gaspillé. Dans ce sens, le code source est considéré comme un artefact.

«Artefact» comme quelque chose produit par une recette - Ce sens utilise l'image populaire de l'alchimiste utilisant une recette ésotérique pour produire un dispositif magique, souvent appelé un artefact. C'est un jargon technique utilisé pour distinguer le code source, qui correspond à la recette dans la métaphore de l'alchimiste, et tout ce qui dérive de ce code source, qui correspond à un artefact dans la métaphore de l'alchimiste. Par exemple, je viens d'automatiser la production d'artefacts pour mon programme plop-fizz, maintenant les archives tar, les fichiers de signature, les paquets DEB et RPM peuvent tous être instanciés en une seule commande! Cette signification ne reconnaît pas le code source comme un artefact, car le terme est utilisé pour désigner ce qui est produit à partir de ce code source.

Je suppose que la réponse peut varier d'un endroit à l'autre. Là où je travaille en ce moment, un artefact est tout ce qui est consommé par une autre entité, à l'exception du code source utilisé pour le développement - cela va dans le contrôle de source.

Cela inclut les fichiers binaires du produit ou d'autres produits nécessaires, les bibliothèques, les fichiers objets, les artefacts de test comme les fichiers multimédias ou les données de test.

Le code source n'est pas considéré comme un artefact. Sauf s'il correspond à la définition de «consommé par» - dans notre cas, y compris les bibliothèques tierces, le code de script utilisé à des fins de test ou à d'autres fins (mais pas la version de développement elle-même).

Note côté culture. Alors que dans DevOps, nous considérons le concept de "référentiel d'artefacts" comme une situation donnée, il semble qu'il n'y ait pas tellement de liens avec le processus organisationnel.

Problème de culture: si une organisation utilise ITIL, les personnes certifiées diraient "nous devons avoir une médiathèque définitive, un tel référentiel pour placer les éléments de configuration logicielle que nous avons produits". Ainsi, les personnes qui se soucient de processus informatiques bien structurés ne savent pas quels outils (non de gestion) prennent en charge cela et sont utilisés. Inversement, si vous avez besoin d'une justification pour un langage Nexus ou Artifactory, vous pourriez avoir du mal à l'expliquer en fonction de l'organisation.

Pour en savoir plus: https://en.wikipedia.org/wiki/Definitive_Media_Library