Industrialiser une chaîne de livraison et passer au GitOps sans tout casser

La plupart des chaînes de livraison que nous auditons ont le même profil : quarante minutes de compilation et de tests, un taux d'échec élevé, et une mise en production manuelle qui concentre tout le risque. La reconstruction commence toujours par une mesure, jamais par un outil.

Étape 1 : mesurer avant de toucher

Nous relevons quatre chiffres sur les trente dernières exécutions : durée totale, durée d'attente avant démarrage, taux d'échec, et part des échecs attribuables à l'infrastructure plutôt qu'au code. Ce dernier point est souvent révélateur : quand un tiers des échecs vient de l'environnement, corriger les tests ne sert à rien.

• Durée totale et durée d'attente avant démarrage.
• Taux d'échec global, et part liée à l'infrastructure.
• Temps moyen de correction après un échec détecté.
• Nombre de versions déployées capables d'être reconstruites à l'identique.

Étape 2 : découper le pipeline par objectifs

Un pipeline utile se lit comme une séquence de questions. Chaque étape répond à une question unique, et son échec doit être compréhensible par la personne qui doit corriger, sans consulter un journal de mille lignes.

Le piège de l'étape fourre-tout

Beaucoup de chaînes accumulent les vérifications dans une seule étape, ce qui rend l'échec illisible et empêche toute parallélisation. Séparer les étapes permet de lancer les tests unitaires, l'analyse statique et la construction d'image en parallèle, puis de n'exécuter les tests lourds qu'après validation des vérifications rapides.

Étape 3 : rendre la version déployée vérifiable

Un déploiement ne devrait jamais reposer sur une supposition. Nous exposons la version construite et l'horodatage de construction dans un point d'entrée technique, interrogé automatiquement après chaque déploiement.

@RestController
class VersionController {

    private final BuildProperties buildProperties;

    VersionController(BuildProperties buildProperties) {
        this.buildProperties = buildProperties;
    }

    @GetMapping("/internal/version")
    VersionResponse version() {
        String time = buildProperties.getTime() == null
                ? "unknown"
                : buildProperties.getTime().toString();
        return new VersionResponse(buildProperties.getVersion(), time);
    }
}

Ce point d'entrée peut sembler anecdotique : il est en réalité la condition d'un diagnostic rapide. Sans lui, savoir quelle version tourne réellement sur un environnement demande de consulter un registre, un tableau de bord et parfois le journal d'un conteneur.

Étape 4 : basculer le déploiement en GitOps

Le GitOps déplace la question du déploiement : on n'applique plus des commandes, on décrit un état attendu. Le dépôt de configuration devient la source de vérité, et tout écart constaté sur le cluster est une anomalie à expliquer.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: billing-api-staging
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://example.com/git/platform-config
    targetRevision: main
    path: environments/staging/billing-api
  destination:
    server: https://kubernetes.default.svc
    namespace: billing
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=false

Le retour arrière devient une opération ordinaire : on revient à la révision précédente du dépôt de configuration. Cette simplicité a une condition : les migrations de base de données doivent rester compatibles avec la version précédente du code pendant au moins une livraison.

Une chaîne de livraison se juge au temps qu'il faut pour savoir qu'un changement est mauvais, pas au nombre d'étapes qu'elle contient.

Étape 5 : entraîner l'équipe sur un cas réel

La dernière étape consiste à provoquer volontairement une panne en environnement de recette : image défectueuse, migration incompatible, dépendance indisponible. L'équipe exécute le retour arrière, puis nous corrigeons la documentation en fonction de ce qui a réellement été nécessaire. Cette séance révèle en général deux ou trois procédures manquantes que personne n'avait identifiées.

Ce qu'il faut retenir

L'industrialisation d'une chaîne de livraison n'est pas un projet d'outillage : c'est un travail de réduction du délai de retour d'information. Commencez par la mesure, découpez par question, rendez la version déployée vérifiable, puis basculez le déploiement en GitOps. Le reste suit naturellement.