Ce qui se passe après la fin de votre pipeline : actions postérieures, nettoyage et preuves
Vous venez de voir votre pipeline passer au vert. Tous les tests ont réussi, le déploiement est terminé, et le chat d'équipe a reçu un rapide message "fait". La plupart des gens ferment l'onglet et passent à la tâche suivante. Mais si vous vous arrêtez là, vous laissez le pipeline à moitié terminé.
Un pipeline n'est pas complet simplement parce que le déploiement a fonctionné. Il y a trois choses qui doivent se produire après le dernier test réussi, et les ignorer crée des problèmes qui n'apparaissent que des semaines ou des mois plus tard.
Des notifications vraiment utiles
La première chose que votre pipeline devrait faire lorsqu'il se termine est d'informer quelqu'un. Mais toutes les notifications ne sont pas utiles. Un message qui dit simplement "déploiement réussi" ou "build échoué" est du bruit. Il oblige les gens à ouvrir les logs du pipeline juste pour comprendre ce qui s'est passé.
Une bonne notification apporte du contexte. Elle doit inclure :
- Quel changement a été traité (hash de commit ou ID de merge request)
- Qui a déclenché le pipeline
- Quel environnement a reçu le déploiement
- Si tout a réussi ou si quelque chose a échoué
- Un lien direct vers l'exécution du pipeline
Pour une petite équipe, un message de chat suffit. Pour les grandes organisations, vous pouvez envoyer des notifications par e-mail, vers des trackers de tickets ou des tableaux de bord de monitoring. Le support importe moins que le contenu. Si votre notification n'aide pas quelqu'un à décider s'il doit agir, ce n'est qu'une distraction supplémentaire.
Pensez à la personne qui reçoit une alerte à 2 heures du matin parce que la production se comporte étrangement. Elle a besoin de savoir immédiatement : y a-t-il eu un déploiement récent ? Qui l'a fait ? Qu'est-ce qui a changé ? Une notification bien structurée répond à ces questions avant que quiconque n'ait à ouvrir un navigateur.
Voici un extrait YAML pratique pour une étape de notification Slack qui inclut le contexte essentiel :
notify-slack:
stage: post-deploy
image: curlimages/curl:latest
script:
- |
curl -X POST -H "Content-type: application/json" \
--data "{
\"text\": \"Deployment complete\",
\"blocks\": [
{
\"type\": \"section\",
\"text\": {
\"type\": \"mrkdwn\",
\"text\": \"*Pipeline finished*\nCommit: \`$CI_COMMIT_SHORT_SHA\`\nAuthor: $GITLAB_USER_LOGIN\nEnvironment: production\nStatus: $CI_JOB_STATUS\nLink: $CI_PIPELINE_URL\"
}
}
]
}" \
$SLACK_WEBHOOK_URL
only:
- main
Cette étape s'exécute uniquement sur la branche principale, envoie le hash du commit, l'auteur, l'environnement et un lien direct vers le pipeline, afin que toute personne qui la reçoit puisse immédiatement évaluer la situation sans ouvrir les logs.
Nettoyer les ressources temporaires
Chaque fois qu'un pipeline s'exécute, il crée des ressources temporaires. Un espace de travail sur le runner. Des conteneurs qui ont été lancés pour les tests. Des volumes de stockage temporaires. Des artefacts de build qui n'étaient nécessaires que pendant la phase de construction. Des dépendances téléchargées.
Si vous ne nettoyez pas tout cela, cela s'accumule. L'espace disque se remplit. Les runners ralentissent. Et pire encore, l'état résiduel d'un pipeline peut interférer avec l'exécution suivante. Un test qui réussit localement peut échouer en CI parce que l'espace de travail contient encore des fichiers d'un build précédent.
Le nettoyage doit être automatique. Ne comptez pas sur quelqu'un qui se souvient de supprimer les choses manuellement. La plupart des plateformes de pipeline ont des mécanismes de nettoyage intégrés, mais vous devez vérifier qu'ils fonctionnent réellement pour votre configuration spécifique. Un conteneur nettoyé par la plateforme peut encore laisser des volumes montés. Un espace de travail effacé peut encore contenir des identifiants en cache.
L'approche la plus sûre est de faire du nettoyage une étape explicite à la fin de votre pipeline. Supprimez ce que vous avez créé. Démontez ce que vous avez monté. Retirez ce que vous avez mis en cache. Si votre plateforme de pipeline gère une partie de cela automatiquement, tant mieux. Mais ajoutez une étape pour les choses qu'elle pourrait oublier.
Stocker les preuves : la partie que tout le monde oublie
C'est l'action postérieure la plus importante, et celle que la plupart des équipes sautent.
Les preuves sont un enregistrement complet de tout ce qui s'est passé pendant l'exécution du pipeline. Pas seulement le statut final, mais toute l'histoire :
- Ce qui a déclenché le pipeline
- Quel commit a été traité
- La sortie du build et les logs
- Les résultats des tests, y compris quels tests ont réussi et lesquels ont échoué
- Les rapports de scan de sécurité
- L'artefact exact qui a été produit (avec son hash ou l'URL du registre)
- Les logs de déploiement
- Les résultats de vérification des contrôles post-déploiement
Tout cela doit être sauvegardé dans un endroit accessible. Pas enterré dans le stockage interne d'une plateforme CI qui expire après 30 jours. Pas dans l'historique du terminal local de quelqu'un. Quelque part qui peut être interrogé des mois ou des années plus tard.
Pourquoi est-ce important ? Parce qu'un jour, quelqu'un demandera :
- "Cette version que nous avons déployée en production il y a trois semaines, a-t-elle passé le scan de sécurité ?"
- "Nous avons un incident en production. Ce changement a-t-il été testé avec la migration de base de données ?"
- "L'auditeur veut voir la preuve que chaque déploiement a été revu avant d'être mis en production."
Sans preuves, vous ne pouvez pas répondre à ces questions. Vous devez deviner. Et deviner lors d'incidents de production ou d'audits, c'est ainsi que les carrières sont compromises.
Comment stocker les preuves de manière pratique
Vous n'avez pas besoin d'un fichier géant qui contient tout. Cela devient rapidement ingérable. Stockez plutôt des références et des liens.
Votre pipeline devrait produire un résumé qui contient :
- L'ID du build et un lien vers les logs du build
- L'URL de l'artefact dans votre registre
- Un lien vers le rapport de test
- Un lien vers les résultats du scan de sécurité
- L'emplacement des logs de déploiement
- Tout enregistrement d'approbation manuelle
Ce résumé peut être stocké dans votre système de gestion des changements, un bucket de stockage d'objets, ou même une base de données. Le format peut être JSON, YAML ou texte brut. Ce qui compte, c'est que les humains et les machines puissent le lire.
Certaines équipes attachent ces preuves au commit ou à la merge request elle-même. D'autres les stockent dans un dépôt de preuves dédié. Les deux fonctionnent, tant que c'est recherchable et que cela n'est pas supprimé automatiquement.
Les preuves ne sont pas seulement pour les auditeurs
Oui, les auditeurs adorent les preuves. Mais la vraie valeur apparaît lors du débogage.
Quand la production plante, la première question est toujours : "Qu'est-ce qui a changé ?" Avec de bonnes preuves, vous pouvez ouvrir la dernière exécution du pipeline et voir exactement ce qui s'est passé. Y a-t-il eu un test qui a échoué mais a été ignoré ? L'artefact était-il différent de ce que vous attendiez ? Y a-t-il eu un changement de configuration que personne n'a documenté ?
Sans preuves, vous déboguez à l'aveugle. Vous vous fiez à la mémoire, aux logs de chat et aux suppositions. Avec des preuves, vous avez un enregistrement factuel de ce qui s'est réellement produit.
Boucler le cycle du pipeline
Une fois les notifications envoyées, les ressources nettoyées et les preuves stockées, le cycle du pipeline est vraiment terminé. Le pipeline est prêt pour le prochain déclencheur, et la même séquence se répétera.
Ce rythme est ce qui rend la CI/CD fiable. Chaque changement suit le même chemin. Chaque changement laisse le même type de trace. Chaque changement produit une sortie qui peut être vérifiée plus tard.
Liste de contrôle rapide pour l'étape post-action de votre pipeline
- Les notifications incluent le commit, l'auteur, l'environnement et le statut avec un lien direct
- Les ressources temporaires sont nettoyées automatiquement
- Les logs de build, les résultats de test et les rapports de scan sont stockés de manière permanente
- Les références aux artefacts (URL du registre, hash) sont enregistrées
- Les logs de déploiement sont sauvegardés et liés
- Les preuves sont stockées dans un emplacement recherchable et non expirable
L'essentiel à retenir
Un pipeline qui s'arrête à "déploiement réussi" est incomplet. Ajoutez trois étapes après votre déploiement : notifier avec un contexte utile, nettoyer les ressources temporaires et stocker des preuves qui peuvent être retrouvées des mois plus tard. La dernière étape est celle qui vous sauve quand les choses tournent mal. Sans elle, vous volez à l'aveugle. Avec elle, vous avez un enregistrement factuel qui transforme le débogage de supposition en investigation.