Où que vous lisez sur livraison continue ou intégration continue il est recommandé d'utiliser un référentiel d'artefact pour stocker les objets même si Jenkins les stocke déjà pour chaque construction.Quel est le but d'un référentiel d'artefacts?
Alors pourquoi est-il recommandé d'utiliser un référentiel d'artefacts? Y a-t-il une solution lisse pour travailler avec les artefacts des builds de Jenkins, ex. utiliser ces artefacts pour le déploiement?
un référentiel d'artefact et outils d'intégration continue servent deux fins différentes et on ne peut pas être substitué avec l'autre. Vérifiez this video de Artifactory, l'un des fournisseurs de référentiels d'artefacts, sur la raison pour laquelle il faut utiliser un référentiel d'artefacts. Jenkins stocke les artefacts sous forme de fichiers simples sans versioning tandis que les artefacts dans un référentiel d'artefacts peuvent être contrôlés par la version. Vous avez donc beaucoup plus de flexibilité pour récupérer les artefacts et les gérer. Lire this très bon article sur pourquoi nous avons besoin d'eux. Sûrement pas toutes ces choses sont soutenues par des outils d'intégration continue comme Jenkins. En outre, vous pouvez également regarder le Artifactory plugin for Jenkins qui intègre les deux.
Je n'ai pas tenu à jour avec Jenkins, nous utilisons toujours une version de l'IC quand il s'appelait Hudson.
Dans vos projets, vos poms devraient normalement pointer vers votre propre référentiel d'artefacts où vous pourrez récupérer et déployer vos propres projets (d'entreprise). En utilisant un référentiel d'artefacts avec votre serveur CI, il peut ensuite déployer avec succès un snapshot et des versions qui peuvent être disponibles pour d'autres développeurs.
Un référentiel d'artefacts est nécessaire mais le repo d'artefacts est une pièce conceptuelle qui n'est pas toujours un outil distinct. Avec Jenkins, vous devriez avoir des signatures MD5 et (je pense) un moyen de télécharger les fichiers que vous voulez (appel de service Web, non?) À partir de votre serveur distant. Certainement, si vous faites quelque chose de simple comme utiliser le plugin Jenkins build pipeline, il devrait être en mesure d'accéder aux bonnes versions des fichiers en douceur. Sinon, si vous utilisez un outil de déploiement distinct, les meilleurs regroupent un référentiel d'artefacts. Quoi qu'il en soit, vous voulez ce que les gens d'ITIL appellent une bibliothèque média/logiciel définitive. Définitif en ce que les bits sont sécurisés, fiables et officiels. Et une bibliothèque dans laquelle ils peuvent être facilement consultés et accessibles. Lorsque vous travaillez avec un référentiel d'artefacts, vous devez vous assurer qu'il est correctement sécurisé. Il est sauvegardé. Il est accessible pour vos déploiements (y compris en production). Si vous regardez Jenkins et qu'il répond à vos critères dans ces catégories, considérez-vous fait. Si ça manque, et je ne serais pas surpris si c'était le cas, alors vous avez besoin soit d'un outil dédié comme les repos Maven, ou quelque chose de regroupé avec l'outillage de déploiement.
Pour plus de mes randonnées sur le sujet, il y a un recorded webcast. Les diapositives pour cela sont en hausse sur Slideshare.