Gestionnaire de dépôt d'objets binaires
Un gestionnaire de dépôts d'objets binaires (binary repository manager en anglais) est un outil logiciel conçu pour optimiser le téléchargement et le stockage des objets binaires utilisés et produits dans le cadre du développement de logiciels (généralement des fichiers). Il centralise la gestion de tous les artéfacts générés et utilisés par les logiciels de l'organisation (éditeur logiciel). Il permet de répondre à la problématique de complexité découlant de la diversité des types d'objets binaires, de leur position dans l'ensemble du flux de travail ainsi que les dépendances entre eux.
Un dépôt d'objets binaires est un dépôt de logiciels pour les paquets, artefacts et leurs métadonnées. Il peut être utilisé pour stocker les fichiers binaires produits par l'organisation elle-même (releases et builds intermédiaires des produits) ou pour stocker les binaires tiers (dépendances) qui doivent être traités différemment pour des raisons techniques et juridiques.
Introduction
Le développement de logiciels peut être un processus complexe[1] - [2] impliquant de nombreux développeurs, possiblement dans plusieurs pays (problématique des fuseaux horaires, barrière des langues...). Ces équipes de développeurs partagent les mêmes dépôts de code, l'accès aux mêmes outils de build, téléchargent et utilisent un ensemble commun de ressources binaires et déploient les mêmes composants au sein du même logiciel.
Le gestionnaire de dépôt d'objets binaires a été créé pour venir centraliser les artéfacts binaires dont les applications ont besoin pour être construites (compilation), testées et exécutées.
Convergences et divergences avec les gestionnaires de versions
Pour gérer les fichiers de code source dans le développement de logiciels, les organisations utilisent généralement le contrôle de révision. Ce logiciel a pour objectif de centraliser le code source d'un logiciel permettant à plusieurs personnes de travailler simultanément dessus et permettant également (entre autres fonctionnalités) de conserver l'historique des modifications effectuées sur chaque fichier. Pour cela les gestionnaires intègrent ou utilisent des outils tels que des comparateurs de textes (diff).
Ces nombreux fichiers source sont finalement intégrés (compilés ou non) dans un ou plusieurs artéfacts binaires et constituent les composants d'un produit logiciel.
Convergences
Le résultat des compilations et constructions de composants est soumis aux mêmes principes que les fichiers sources (pérennisation, disponibilité, historique...). Le gestionnaire de dépôt d'objets binaires converge donc vers les gestionnaires de versions et peut être considéré comme un gestionnaire de version pour objets binaires. Il pallie ainsi la limitation qu'ont les gestionnaires de versions (textuels) en matière de manipulation de contenus binaires qu'ils sont obligés de stocker tel quel car incapables d'analyser leur contenu et prenant ainsi beaucoup de place dans des bases de données non prévues et peu performantes pour ce type de contenu.
En outre, les logiciels peuvent faire appel à des artéfacts extérieurs (mis à disposition par un ou plusieurs tiers) qui sont téléchargés à partir de dépôts (libres, open-source ou propriétaires) et/ou acquises (gratuitement ou achetés auprès de sources commerciales[3]). Ainsi, un logiciel peut comprendre des dizaines, des centaines voire des milliers d'objets binaires qui doivent être gérés afin de maintenir efficacement un ensemble cohérent et fonctionnel.
Comme pour les gestionnaires de versions, les gestionnaires de dépôt d'objets binaires sont partagés par les différentes équipes de développement garantissant ainsi que tout le monde utilise les mêmes ressources.
Divergences
Le gestionnaire de dépôt d'objets binaires diverge par rapport aux gestionnaires de version en ceci qu'il doit intégrer un ensemble d'éléments qui ne sont pas la propriété de l'organisation (contraintes légales à prendre en compte). De fait, il est donc responsable de la création et du maintien d'un contexte (environnement) historique dans lequel un logiciel est créé permettant de le recréer si nécessaire sans risques de variations dues aux cycles de vie des composants internes et tiers.
Contrairement aux gestionnaires de versions, les gestionnaires de dépôt d'objets binaires n'ont pas pour objectif de stocker toutes les évolutions intermédiaires des artéfacts comme le font les gestionnaires de versions pour les fichiers de code source. Seules les versions estampillées comme telles (via les métadonnées) sont stockées et accessibles.
Il est une pratique courante que d'avoir une version particulière (voire plusieurs quand le projet gère plusieurs versions en parallèle) dite snapshot ou nightly build sur laquelle l'organisation travaille et qui est susceptible de changer fréquemment. Cette version n'est généralement pas mise à disposition des autres équipes de développement et son historique n'est pas conservé, seule la dernière version créée est accessible les autres sont écrasées.
Quand la version est figée (validée) un numéro de version définitif est créé et le gestionnaire de dépôt d'objets binaires stocke les éléments créés dans un artéfact précis et l'ensemble ne subira plus d'évolution. Les corrections de bugs seront réalisées dans une version séparée identifiée par un autre numéro de version.
Le gestionnaire de dépôt d'objets binaires ne gère donc pas la notion de branche comme les gestionnaires de version puisqu'il n'est pas possible de réaliser de fusion (merge) de branches ni de comparaisons. Chaque branche (version au sens du gestionnaire de dépôt d'objets binaires) est complètement indépendante des autres versions du logiciel alors que pour un gestionnaire de version, le contenu d'une branche n'est que la somme des modifications effectuées sur les fichiers à partir du moment où la branche a été créée (la branche n'est donc exploitable qu'associée aux éléments précédents de l'historique).
Gestionnaire universel de paquets
L'industrie du logiciel est en perpétuelle évolution. Les gestionnaires d'objets binaires n'échappent pas à la règle et se dirigent petit à petit vers des gestionnaires universels de paquets[4]. Ces gestionnaires de paquets visent à standardiser la façon qu'ont les entreprises d'accéder et d'utiliser tous les paquets dont elles ont besoin dans leur processus de développement. Ils fournissent des outils de sécurité et d'analyse de compatibilité des types d'artéfacts. Les gestionnaires universels de paquets ont une position centrale dans la chaîne d'outils de développement (systèmes de compilation, empaqueteurs, outils de documentation, d'analyse de code, de livraison...) exploitée par les organisations[5].
Quelques gestionnaires universels de paquets connus[6] :
- Apache Archiva
- Jfrog's Artifactory
- Inedo's ProGet
- Sonatype Nexus
Lien avec le processus d'intégration continu
Dans le cadre du cycle de vie de développement logiciel, le code source est régulièrement compilé dans des objets binaires durant le processus d'intégration continue.
Au cours de cette opération, le système de gestion du code est en interaction avec le gestionnaire de dépôt d'objets binaires pour obtenir les dépendances nécessaires à l'opération de compilation, de traitement et d'exécution ainsi que pour déposer au sein du dépôt d'objets binaires sa propre production (on parle alors de publication). Cette communication passe par l'utilisation d'artéfact permettant d'identifier les ressources nécessaires et mettre à disposition d'autres outils ou logiciels les objets binaires créés.
Cette interaction étroite avec les serveurs d'intégration continue permet le stockage de métadonnées telles que :
- quel utilisateur a lancé l'exécution du build (manuellement ou lors d'un envoi d'information vers le gestionnaire de révision - commit en anglais)
- quels modules sont construits
- quelles sources sont utilisées (identifiant du commit, révision, branche, modifications intervenues depuis le dernier build)
- quelles dépendances sont utilisées
- quel est l'état des variables d'environnement
- quels paquets sont installés
Artéfacts et paquets
Les artéfacts et paquets sont deux choses intrinsèquement différentes.
Les artéfacts représentent un ensemble (parfois réduit à une seule entrée) d'éléments (généralement des fichiers tels que les JAR, WAR, EAR, DLL, SO, ZIP...) dont un contient des métadonnées (par exemple le POM chez Maven) permettant de les identifier de façon unique (id, package, version, licence et autres...).
À contrario, les paquets sont constitués d'un fichier archive unique répondant à un format bien défini (par exemple NuGet de Microsoft, RPM de Red Hat ou DEB de Debian). Cette archive contient l'ensemble des fichiers prévus par le format (tels que des DLL, PDB...)[7].
Les artéfacts sont généralement générés par des builds. Les paquets sont essentiellement des librairies logicielles ou des applications[8].
Comparativement aux fichiers sources, les artéfacts binaires sont beaucoup plus gros. Ils sont rarement supprimés ou modifiés (exception faite des artéfacts en cours de développement qui sont régulièrement écrasés par des mises à jour et qui ne sont pas officiellement disponibles pour les tiers).
Métadonnées
Les métadonnées décrivent un artéfact binaire. Elles sont stockées séparément de l'artéfact lui-même et peuvent avoir différentes utilisations.
Le tableau suivant présente les types métadonnées les plus courantes et leur utilisation.
| Types | Utilisations |
|---|---|
| Versions disponibles | permet la mise à jour ascendante (upgrade) ou descendante (downgrade) |
| Dépendances | spécifie les artéfacts dont dépend l'artéfact décrit |
| Dépendances d'impact | donne la liste des artéfacts dépendant de l'artéfact décrit |
| Licence | contenu (ou référence) de la licence légale à laquelle est soumis l'artéfact décrit (ex: GPL, CC, Apache...) |
| Date et heure du build | permet la traçabilité de l'artéfact |
| Documentation | fournit la documentation hors ligne de l'artéfact |
| Information d'approbation | indique la traçabilité du processus de validation et d'approbation de l'artéfact |
| Mesures | agrège les informations relatives à la qualité du code, la couverture des besoins, les résultats de tests... |
| Métadonnées utilisateur | liste les informations complémentaires fournies par les développeurs (rapports, documentation technique, processus...) |
Principales fonctionnalités des gestionnaires de dépôt d'objets binaires
Ci-dessous sont listées les principales fonctionnalités fournies par les gestionnaires de dépôt d'objets binaires et qui doivent être prises en compte lors de le l'adoption de tels systèmes[9]:
- gestion de cache : dans le but d'améliorer les performances d'accès pour les réseaux à bas débit, le gestionnaire réalise localement une copie du dépôt général (cache) de façon à limiter les aller/retour entre le client et le serveur distant ; ceci augmente également la robustesse vis-à-vis des pannes système et réseau tout en permettant de travailler hors-ligne si nécessaire
- politique de rétention : pour limiter l'espace disque utilisés par le dépôt, le gestionnaire offre la possibilité de définir des règles de conservation des artéfacts (liste de versions autorisées, délai de conservation dans le temps...) ; il est alors en mesure de purger le système des éléments périmés ou ne répondant plus aux règles définies
- filtrage de licence : les artéfacts externes (tiers) sont susceptibles d'être soumis à conditions légales (licences) et donc à un circuit d'approbation interne à l'organisation, le gestionnaire offre donc la possibilité de limiter le type de licences autorisées de façon que les développeurs ne puissent pas faire appel à des librairies non autorisées par méconnaissance
- haute disponibilité : vu que le gestionnaire de dépôt est responsable des dépendances logicielles nécessaires au développement, il est vital que l'accès à ces artéfacts soit toujours possible (toute interruption de service du gestionnaire peut avoir de lourdes conséquences sur l'avancement des développements de l'organisation) ; c'est pourquoi une haute disponibilité est nécessaire pour limiter ces problématiques ; ceci est résolu par la mise en place de redondances de gestionnaires de dépôt d'objets binaires dans le réseau ; ces gestionnaires utilisent la même base de données et les mêmes stockages de fichiers ; ils permettent d'assurer la stabilité et les performances du système dans le temps
- restrictions utilisateurs : le gestionnaire de dépôt d'objets binaires peut être intégré aux systèmes internes à l'organisation comme les LDAP ou les SSO pour simplifier et gérer de manière centralisée les utilisateurs ; il fournit un moyen pour l'organisation de garder le contrôle de l'accès aux composants logiciels vitaux
Voir aussi
Références
- (en) Johnny Biggert, « SUSTAINABLE SOFTWARE DEVELOPMENT, PART 2: MANAGING COMPLEXITY », sur Developers Dilemma, Johnny Biggert (consulté le )
- (en) « Managing Complexity », sur The Economist, The Economist (consulté le )
- (en) « Eighth Annual Future of Open Source Survey Finds OSS Powering New Technologies, Reaching New People, and Creating New Economics », sur blackducksoftware.com (consulté le )
- (en) John K. Waters, « JFrog Releases ‘Universal’ Artifact Repository », sur ADT Mag, Application Development Trends Magazine,
- (en) Xavier Decoster, « An Overview of the NuGet Ecosystem », sur CodeProject.com,
- (en) scott hanselman, « How to host your own NuGet Server and Package Feed », sur Hanselman.com,
- (en) Chris Tucker, « OPIUM: Optimal Package Install/Uninstall Manager », UC San Diego, , p. 10 (lire en ligne)
- (en) « Linux repository classification schemes », braintickle.blogspot.com (consulté le )
- (en) Adrian Bridgewater, « How to find real DevOps, look for binary artifact repository control », sur ComputerWeekly.com,