Expliquez-moi comment vous concevriez un pipeline CI/CD pour un service qui part en production plusieurs fois par jour.

Chaque commit déclenche un seul pipeline qui construit un artefact unique et immuable, le teste, et promeut ce même artefact d'un environnement à l'autre ; rien n'est reconstruit par environnement. Gardez les étapes de retour rapide en premier (lint, tests unitaires, build) pour que les échecs remontent en quelques minutes, lancez les tests d'intégration et les scans de sécurité en parallèle, puis déployez automatiquement en staging et en production derrière une livraison progressive avec retour arrière automatisé.

Le principe de base, c'est construire une fois et promouvoir le même artefact. À chaque commit, le pipeline construit une image de conteneur taguée avec le sha du commit, et c'est exactement ce digest qui finit par tourner en production, donc rien n'est reconstruit avec des dépendances différentes à mi-parcours. L'ordre des étapes suit le temps de retour : lint et tests unitaires d'abord pour qu'un mauvais changement échoue en deux minutes environ, puis le build de l'image, puis les tests d'intégration, les tests de contrat et le scan de sécurité en parallèle puisqu'aucun ne dépend des autres. Le merge sur main déploie automatiquement en staging et lance les tests de fumée. La production, c'est le même pipeline avec une livraison progressive, donc dix pour cent du trafic d'abord pendant qu'on surveille le taux d'erreur et la latence par rapport à la référence, et un retour arrière automatique en cas de dépassement. Je garde la définition du pipeline dans le même dépôt que le code pour qu'elle soit relue comme le reste, et je suis deux ou trois chiffres sur le pipeline lui-même, surtout le temps qu'un changement met pour atteindre la production et le pourcentage de builds verts sur main.