Comment j'automatise les pipelines de build, test et release pour des microservices et des API

Pourquoi la plupart des pipelines de microservices sont trop fragiles

Quand un système comporte dix microservices, la tentation est de copier-coller un seul YAML de pipeline dix fois et de considérer le travail terminé. Je l'ai fait. Ça casse à l'échelle — un changement de modèle doit être appliqué dix fois, les divergences s'accumulent, et déboguer un build en échec revient à lire 400 lignes de YAML que vous n'aviez pas l'intention d'écrire.

Voici comment je structure des pipelines qui montent en charge proprement à travers les services sur Azure DevOps.

La structure : modèles partagés, déclencheurs par service

L'idée clé est de séparer le quoi (la logique du pipeline) du lequel (la configuration du service). Une seule bibliothèque de modèles partagés. Des fichiers de pipeline minces par service qui pointent vers elle.

Étape 1 — Build

Chaque pipeline de microservice se déclenche sur son propre chemin source grâce aux filtres de chemin d'Azure DevOps. L'étape de build exécute dotnet build, met en cache les packages NuGet par hash de fichier de verrouillage, et produit un artefact versionné. Le versionnage suit une convention sémantique basée sur le nom de la branche et le numéro de build — aucun tag manuel requis.

Étape 2 — Test

Les tests unitaires et les tests d'intégration s'exécutent en jobs parallèles. Les tests unitaires passent en premier, rapides, sans aucune dépendance externe. Les tests d'intégration démarrent des conteneurs de service Docker (SQL Server, Redis) directement dans le pipeline. Si les tests unitaires échouent, les tests d'intégration ne démarrent pas — retour rapide, aucune minute perdue.

La couverture de code est collectée via Coverlet et publiée dans les analyses de tests d'Azure DevOps. Un seuil de couverture bloque le pipeline s'il descend en dessous du minimum requis.

Étape 3 — Release

L'étape de release construit une image Docker, la pousse vers Azure Container Registry, et déclenche un déploiement progressif vers AKS via Helm. Les valeurs spécifiques à l'environnement — chaînes de connexion, feature flags, secrets — sont injectées depuis Azure Key Vault au moment du déploiement. Jamais codées en dur dans le YAML, jamais commises dans le dépôt.

L'erreur qui m'a coûté deux incidents en production

Au début, je laissais l'étape de release s'exécuter automatiquement à chaque fusion vers main — y compris pour les services qui n'avaient pas changé. Une bibliothèque partagée cassée pouvait alors se propager et déclencher des déploiements simultanés sur tous les services.

La solution : la détection de changements. Chaque pipeline vérifie si le chemin source du service a changé depuis la dernière exécution réussie. Les services inchangés sont entièrement ignorés. Le rayon d'impact d'un déploiement passe de « tout » à « exactement ce qui a changé ».

« Un pipeline devrait déployer le minimum nécessaire pour refléter ce qui a changé — pas tout ce qui pourrait potentiellement avoir besoin d'être mis à jour. »

Ce que j'ajouterais si je recommençais aujourd'hui

La détection de dérive dès le premier jour — un pipeline nocturne qui vérifie si le SHA de l'image déployée correspond à la version d'artefact attendue. La dérive silencieuse dans des conteneurs longue durée est plus fréquente qu'on ne le pense, et la détecter de manière proactive vaut mieux que de la découvrir en pleine incident à 2h du matin.

C'est la même discipline de déploiement qui tourne derrière Contractly Pro — chaque version passe par le même pipeline testé avant d'atteindre les freelances qui comptent dessus pour leurs contrats et leur facturation. Essayer Contractly Pro gratuitement →