Pourquoi chaque artefact a besoin d'un nom et d'un numéro

Votre équipe compile du code tous les jours. Vendredi, vous avez sept artefacts différents dans votre dépôt. Personne ne se souvient lequel a été testé, lequel contient le correctif urgent, et lequel doit partir en production. Quelqu'un demande : "Quel build déploie-t-on ?" et la réponse est un haussement d'épaules.

C'est le moment où vous réalisez que des artefacts sans nom clair ne sont pas vraiment des artefacts. Ce ne sont que des fichiers. Sans un système de nommage et de numérotation approprié, votre pipeline produit du bruit au lieu de certitude.

Le problème des artefacts non étiquetés

Lorsque les artefacts n'ont pas d'identité claire, chaque déploiement devient un jeu de devinettes. Les équipes commencent à se fier aux horodatages, aux noms de dossiers ou à leur mémoire. "Je pense que le build de mardi après-midi avait le correctif." Ce genre de raisonnement est dangereux. Il conduit à déployer la mauvaise version, à revenir à quelque chose qui n'a jamais été testé, ou pire, à déployer un artefact cassé parce que personne ne pouvait dire lequel était le plus récent.

Le problème fondamental est simple : si vous ne pouvez pas identifier un artefact de manière unique, vous ne pouvez pas le déployer de manière fiable. Et si vous ne pouvez pas déployer de manière fiable, vous ne pouvez pas livrer en toute confiance.

Ce qui rend un artefact identifiable

Chaque artefact a besoin de deux choses : un nom et un numéro. Le nom indique ce qu'est l'artefact. Le numéro indique de quelle version il s'agit. Ensemble, ils créent un identifiant unique que tous les membres de l'équipe peuvent utiliser sans ambiguïté.

Le nom est généralement le nom de l'application ou du composant. Le numéro est la version. En les combinant, vous obtenez quelque chose comme payment-service-2.1.3. Cette chaîne pointe vers exactement un artefact. Pas celui de la semaine dernière. Pas celui avec un nom similaire. Juste celui-là.

Le versioning n'est pas qu'une formalité

Le versioning est le système qui donne un sens à la partie numérique de votre identifiant d'artefact. Ce n'est pas juste un compteur qui augmente. Un bon système de versioning vous renseigne sur l'artefact lui-même. Il communique la nature du changement, le niveau de risque et la relation avec les versions précédentes.

Le système le plus utilisé est le versioning sémantique. Il utilise trois nombres séparés par des points : MAJEUR.MINEUR.CORRECTIF. Chaque nombre a une signification spécifique.

• MAJEUR augmente lorsque vous apportez des modifications qui cassent la rétrocompatibilité. Si les utilisateurs existants doivent modifier leur code ou leur flux de travail, c'est un changement de version majeure.
• MINEUR augmente lorsque vous ajoutez de nouvelles fonctionnalités qui fonctionnent toujours avec l'ancienne façon de faire. Les utilisateurs peuvent mettre à niveau sans rien casser.
• CORRECTIF augmente pour les corrections de bugs qui n'introduisent pas de nouvelles fonctionnalités et ne cassent pas les fonctionnalités existantes.

Quand vous voyez la version 2.1.3, vous savez que l'application a subi deux changements majeurs cassant la rétrocompatibilité, une ajout de fonctionnalité et trois corrections de bugs. C'est beaucoup d'informations contenues dans une petite chaîne.

L'immutabilité commence avec le versioning

Le numéro de version n'est pas qu'une étiquette. C'est un contrat. Une fois qu'un artefact est construit et étiqueté avec une version, cette version ne doit jamais changer. Si vous reconstruisez le même code, vous devez obtenir le même artefact. Si quelque chose change, la version doit changer.

C'est ce qui rend un artefact immuable. La version 2.1.3 fait toujours référence au même binaire, à la même image conteneur, au même paquet. Peu importe que vous le téléchargiez aujourd'hui, la semaine prochaine ou six mois plus tard. L'artefact est identique. Cette certitude est ce qui vous permet de tester quelque chose en préproduction, puis de déployer exactement la même chose en production sans surprise.

Versioning et livraison sont deux choses différentes

Une erreur courante est de traiter le versioning et la livraison comme un même concept. Ce n'est pas le cas. Le versioning consiste à étiqueter l'artefact. La livraison consiste à décider de rendre cet artefact disponible aux utilisateurs.

Vous pouvez construire la version 2.2.0-beta et la déployer en préproduction pour des tests. Cette version existe en tant qu'artefact, mais ce n'est pas une livraison. Après les tests, vous pouvez décider de la promouvoir en 2.2.0 et de la livrer en production. Ou vous pouvez trouver des problèmes et construire une 2.2.1 à la place.

Cette séparation vous donne de la flexibilité. Vous pouvez construire et versionner des artefacts fréquemment, mais ne livrer que lorsque vous êtes confiant. Le numéro de version suit l'identité de l'artefact. La décision de livraison suit son état de préparation.

Implications pratiques pour votre pipeline

Une fois que vous avez un système de nommage et de versioning clair, plusieurs choses deviennent plus faciles.

La traçabilité devient automatique. Lorsqu'un bug est signalé en production, vous regardez la version qui s'exécute dans cet environnement. Vous vérifiez quels changements sont allés dans cette version. Vous la comparez avec la version stable précédente. Tout cela est possible parce que chaque artefact a un identifiant unique qui renvoie au code source et au processus de construction.

Le rollback devient précis. Vous ne devinez pas quelle version fonctionnait avant. Vous savez exactement quelle version était exécutée la semaine dernière, et vous pouvez déployer ce même artefact à nouveau. Parce que l'artefact est immuable, vous déployez exactement le même binaire, pas une reconstruction qui pourrait se comporter différemment.

La communication devient plus claire. Au lieu de dire "déployer le dernier build", vous dites "déployer payment-service 2.1.3 en production". Tout le monde sait exactement ce que cela signifie. Le DBA sait à quelle migration de base de données s'attendre. L'équipe QA sait quels tests ont été exécutés. L'équipe d'exploitation sait quoi surveiller.

Une checklist simple pour le nommage des artefacts

Si vous mettez en place le nommage des artefacts pour la première fois, voici une courte checklist pour commencer :

• Chaque artefact a un nom qui correspond au nom de l'application ou du composant.
• Chaque artefact a un numéro de version qui suit un schéma cohérent.
• Le numéro de version est attribué au moment de la construction et n'est jamais modifié par la suite.
• Le dépôt d'artefacts stocke les artefacts par nom et version, pas par horodatage ou dossier.
• L'équipe comprend la différence entre le versioning (étiquetage) et la livraison (mise à disposition).
• Le système de versioning communique la nature des changements (majeur, mineur, correctif).

Ce qu'il faut retenir

Le nommage et le versioning des artefacts ne sont pas un exercice bureaucratique. C'est le fondement d'un déploiement fiable. Sans cela, votre pipeline produit de l'incertitude. Avec cela, chaque artefact a une identité claire, chaque déploiement a une cible claire, et chaque rollback a une destination claire. Nommez vos artefacts. Numérotez-les de manière cohérente. Rendez-les immuables. Ensuite, vous pourrez déployer en toute confiance.