📦 Pourquoi je préfère livrer sans douleurs avec la promotion d’artefacts ?

C’est bon, votre serveur Nest.JS que vous testez sur l’environnement de DEV depuis quelques semaines marche au poil. Il suffit de cliquer sur un bouton pour le déployer en PROD.

Sauf que voilà, vous utilisez la promotion de code et votre image DOCKER de votre pipeline est configurée en node:latest . C’est cette nuit que la version a été changée en v20 avec tous les superbes changements cassants côté dépendance crypto.

Tant pis ! Pourtant vous l’aviez pourant bien bien testée…

C’est dommage, il aurait pourtant suffi d’utiliser le PACKAGE qui tournait bien en DEV et le déployer, sans ne RIEN CHANGER.

Et je ne sais pas vous, mais sur mes différents projets, il y a toujours au moins deux grandes catégories d’environnements (DEV / PROD) et cela peut monter selon les besoins (UAT, STAGING, PRE-PROD…).

Chaque équipe ayant sa propre inertie, le délai entre chaque étape peut se compter en jours. Alors si je dois re-télécharger à chaque étape mes dépendances, compiler tout en croisant des doigts que l’environnement de BUILD n’ait pas bougé, c’est la porte ouverte à toute les fenêtres.

Comment je faisais avant: la promotion de code

Je poussais sur une branche DEV, c’était parti pour l’INSTALL, BUILD, TESTS et DEPLOY en environnement de DEV.

Quand on voulait déployer en prod, un petit coup de PR sur passage sur une branche RELEASE (PROD par exemple), puis c’était reparti pour INSTALL, BUILD, TESTS et DEPLOY en environnement de (PRE-)PROD

Dans cette approche, c’est la politique de changement de branche qui défini le type d’artefact que je fais.

• Quand je pousse sur DEV, cela déploie sur l’environnement DEV.
• Quand je pousse sur PROD, ça déploie sur l’environnement PROD.

✅ Avantages

• Facile à comprendre, nom de la branche == environnement
• Facile à versionner, la dernière version sur la branche qui passe les tests == la dernière version déployée
• Rapide à mettre en place pour une équipe avec plusieurs personnes

❌ Inconvénients

• Le code est peut être identique, mais rien ne nous assure que les version compilées le soient. Une version DEV peut être différente de PROD. Les dépendances ou l’image docker qui a fait le build sont peut être différentes.
• Plus long à valider, et donc à déployer. Les tests de DEV auront soit été évités, soit été repassés pour le même code (parce qu’artefact différent).

Et maintenant, je préfère la promotion d’artefact (vous savez, déployer la MÊME chose en DEV & PROD)

Je garde toujours une politique de branche. Mais, je décorrèle le déploiement de l’acte de pousser sur une branche.

Il s’agit de deux choses distincts. Le fait de pousser sur une branche déclenche le niveau maximal auquel un artefact peut aller.

• Quand je pousse sur DEV, l’artefact construit n’ira pas plus loin que l’environnement de DEV
• Quand je tag une version release, l’artefact traversera tous les environnements jusqu’à la PROD

Et comment ça se passe ?

• Envoi: Une version est envoyée à mon gestionnaire de version
• Compilation & Packaging: pour générer un artefact optimal, qu’on versionne. Une approche sémantique (Majeur.Mineur.Patch par exemple) c’est un minimum, . Et avec un identifiant unique de build c’est encore mieux (Majeur.Mineur.Patch.Build)!
  Si possible, ajout de suffixe pour différencier les versions DEV / PROD (vous avez le choix: SNAPSHOT, RC… Cette partie là dépend de l’organisation de l’équipe.)
• Tests Statiques: On passe toute la phase d’analyse statique du code (qualité, tests unitaires…) pour ne pas pousser ce qui ne passe déjà pas la première barrière
• Livraison et stockage: La version est livrée sur un gestionnaire d’artefacts (Nexus par exemple) de DEV
• Audits d’artefact: Les étapes de CI de tests et d’audits viennent récupérer l’artefact et s’appuie dessus pour le tester.
• Déploiement de la DEV: On récupère l’artefact et on le pousse dans l’environnement de DEV.

Si la version est identifiée comme “Release”, et que c’est OK, on passe au niveau supérieur !

• Promotion: L’artefact de DEV est promu. Il passe en PROD et est “scellé” : pas possible de pousser une version avec le même numéro ni d’éditer son contenu
• Déploiement des environnements PRE-PROD: Chaque environnement PRE-PROD récupère le dernier artefact et passe les différents tests (Migration, performances, Acceptances…)
• Passage en PROD: lors de la release

Un bug de régression critique est rencontré en PROD ?

Il suffit de cibler une version antérieure fonctionnelle et de lancer le Rollback 🤘
(bien sûr, la gestion de version de la DB c’est un problème tout entier que nous n’aborderons pas ici).

Le must du must: pourquoi un gestionnaire différent pour les artefacts de DEV & de PROD ?

Cela permet une meilleure gestion des droits d’accès en fonction des équipes.

On peut appliquer des politiques différentes : par exemple, les artefacts de développement peuvent être supprimés plus rapidement, tandis que ceux de production doivent être conservés plus longtemps pour garantir un rollback rapide.

✅ Avantages

• 📦 Fiabilité accrue

Avec la promotion d’artefacts, nous savons exactement ce que nous déployons. Rien n’est à ajouter, tout y est. Un artefact qui fonctionne à chaque étape de tests fonctionnera de la même manière en production (sous réserve des différences d’environnement, mais cela ne DEVrait jamais arriver… ou presque 😅).

• 🚀 Gain de temps côté CI & CD

On évite toute l’étape de BUILD & PACKAGE + réduction de certaines étapes du TESTS et du DELIVER (la promotion de l’artefact peut se faire côté gestionnaire d’artefacts directement) ce qui accélère les cycles de livraison.

• 🔎 Facilité d’audit

Chaque artefact est versionné et accessible, ce qui simplifie les audits externes.

Besoin de réaliser des benchmarks de sécurité, de performance ou d’accessibilité sur une version précédente ? Aucun problème ! Tout est à portée de main.

❌ Inconvénients

• Nécessite un cycle de release bien identifié au sein de l’équipe
• Implique des outils particuliers comme un registre d’artefacts, des pipelines bien pensée et une bonne rigueur du flow.

En conclusion

Petit disclaimer de fin : il m’arrive de garder la promotion de code sur des projets encore jeunes avec un cycle de release encore naissant.
Quand un projet est encore en phase de BUILD, il s’agit d’une manière très rapide d’avancer. Surtout si l’entreprise chez qui je suis n’a pas encore de processus bien normé en terme de RELEASE.

Mais, dans une phase de RUN où la stabilité prime, j’ai beaucoup plus confiance dans la promotion d’artefacts.

Cédric CHARIERE FIEDLER

Architecte Web, QA & Perf

# APIFrontQAPerformanceCloud

/in/cedriccf/