Gestionnaire de dépôt d'objets binaires

Joyent

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[modifier | modifier le code]

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[modifier | modifier le code]

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[modifier | modifier le code]

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[modifier | modifier le code]

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[modifier | modifier le code]

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[modifier | modifier le code]

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[modifier | modifier le code]

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[modifier | modifier le code]

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[modifier | modifier le code]

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[modifier | modifier le code]

Articles connexes[modifier | modifier le code]

Références[modifier | modifier le code]

↑ (en) Johnny Biggert, « SUSTAINABLE SOFTWARE DEVELOPMENT, PART 2: MANAGING COMPLEXITY », sur Developers Dilemma, Johnny Biggert (consulté le 11 janvier 2015)
↑ (en) « Managing Complexity », sur The Economist, The Economist (consulté le 11 janvier 2015)
↑ (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 25 février 2015)
↑ (en) John K. Waters, « JFrog Releases ‘Universal’ Artifact Repository », sur ADT Mag, Application Development Trends Magazine, 8 septembre 2015
↑ (en) Xavier Decoster, « An Overview of the NuGet Ecosystem », sur CodeProject.com, 18 août 2013
↑ (en) scott hanselman, « How to host your own NuGet Server and Package Feed », sur Hanselman.com, 13 avril 2015
↑ (en) Chris Tucker, « OPIUM: Optimal Package Install/Uninstall Manager », UC San Diego,‎ 10 mai 2007, p. 10 (lire en ligne)
↑ (en) « Linux repository classification schemes », braintickle.blogspot.com (consulté le 1^er mars 2008)
↑ (en) Adrian Bridgewater, « How to find real DevOps, look for binary artifact repository control », sur ComputerWeekly.com, 1^er novembre 2015

[1] (en) Johnny Biggert, « SUSTAINABLE SOFTWARE DEVELOPMENT, PART 2: MANAGING COMPLEXITY », sur Developers Dilemma, Johnny Biggert (consulté le 11 janvier 2015)

[2] (en) « Managing Complexity », sur The Economist, The Economist (consulté le 11 janvier 2015)

[3] (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 25 février 2015)

[4] (en) John K. Waters, « JFrog Releases ‘Universal’ Artifact Repository », sur ADT Mag, Application Development Trends Magazine, 8 septembre 2015

[5] (en) Xavier Decoster, « An Overview of the NuGet Ecosystem », sur CodeProject.com, 18 août 2013

[6] (en) scott hanselman, « How to host your own NuGet Server and Package Feed », sur Hanselman.com, 13 avril 2015

[7] (en) Chris Tucker, « OPIUM: Optimal Package Install/Uninstall Manager », UC San Diego,‎ 10 mai 2007, p. 10 (lire en ligne)

[8] (en) « Linux repository classification schemes », braintickle.blogspot.com (consulté le 1^er mars 2008)

[9] (en) Adrian Bridgewater, « How to find real DevOps, look for binary artifact repository control », sur ComputerWeekly.com, 1^er novembre 2015

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]