Qu'est-ce qu'un référentiel d'artefacts?


Réponses:


32

Pendant le développement, vous générez une bonne quantité d'artefacts différents. Ceux-ci pourraient inclure:

  • Le code source
  • L'application compilée
  • Un package déployable
  • Documentation

et potentiellement d'autres aussi

Bien que vous puissiez utiliser un système de contrôle de source pour tous les stocker, il est généralement extrêmement inefficace, car les systèmes de contrôle de source sont généralement conçus pour gérer des fichiers texte et non des fichiers binaires. Vous pourriez être en mesure de les utiliser comme un mécanisme de stockage simple, si la plupart de vos versions sont basées sur du texte et que vous n'avez pas à stocker beaucoup de données binaires.

Les référentiels d'artefacts sont cependant conçus pour stocker toutes sortes de fichiers, y compris les fichiers binaires. Cela inclut tout, des codes source zippés aux résultats de construction, en passant par des images comme les images docker. En outre, ils stockent généralement non seulement ces artefacts, mais aident également à les gérer à l'aide de diverses fonctions supplémentaires, par exemple:

  • Prise en charge de la gestion des versions: stockez correctement certaines métadonnées, comme lorsque chaque artefact a été créé, quel est leur numéro de version, stockez leurs hachages, etc.
  • Conservation: assurez-vous de ne conserver que les artefacts importants et de supprimer automatiquement ceux qui ne sont que des instantanés / qui ne sont plus nécessaires, etc. en fonction de divers critères que vous pouvez configurer
  • Contrôle d'accès: définissez qui peut publier et qui peut télécharger les différents artefacts
  • Promotion: capacité à promouvoir des artefacts. Par exemple, vous pouvez avoir des artefacts d'instantané avec une courte période de rétention sur un serveur à proximité de vos codeurs et un référentiel séparé à proximité des serveurs en direct, où seuls les artefacts jugés déployables apparaissent. Cela inclut également la prise en charge de divers canaux de version et le déplacement d'artefacts entre eux (comme la promotion d'une version spécifique de la version bêta à stable).
  • Agir comme un référentiel natif pour les artefacts. Cela signifie que vous pouvez l'utiliser comme référentiel principal pour maven, rubygems, docker, etc. Cela peut également inclure la mise en cache des artefacts des référentiels officiels.

Peut-être vaut-il la peine d'ajouter la fonctionnalité «canal» à la prise en charge de Versionning, ayant la possibilité d'avoir une machine ciblant la dernière version du canal «développer» et une machine de production ciblant une version spécifique dans le canal «stable».
Tensibai

@ Pierre.Vriens a ajouté quelques petits commentaires, mais peut-être que cela peut également être abordé dans une question distincte
SztupY

merci, mais juste au cas où, voici votre chance de répondre davantage à mon commentaire supplémentaire ...
Pierre.Vriens

Est-il judicieux de garder également une trace des fichiers de configuration ou des appareils dans ce type de référentiels?
tutuca

7

Il existe des gestionnaires de référentiels et des gestionnaires de référentiels de packages universels (UPM).

Les UPM peuvent stocker tous vos artefacts de build pour Jenkins, teamcity, etc. et peuvent généralement également servir de gestionnaires de référentiel pour de nombreux types d'artefacts binaires Maven, npm, NuGet et plus encore.

Il s'agirait d'outils comme Jfrog Artifactory , Inedo ProGet et Sonatype Nexus .

Une comparaison assez décente est ici: https://binary-repositories-comparison.github.io/

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.