Un modèle de déploiement qui est vraiment utilisé

Chaque équipe a connu ce déploiement qui a mal tourné parce que quelqu'un a oublié une étape. Peut-être que l'artefact de build n'a jamais été poussé vers le registre. Peut-être que le test de smoke a été sauté parce que "c'est juste une petite modification". Peut-être que le plan de rollback a été discuté en réunion mais jamais écrit, et quand les choses ont cassé, personne n'a pu se mettre d'accord sur la conduite à tenir.

Ces problèmes ne sont pas une question de compétence. Ils sont une question de processus. Quand la pression monte - un incident de production, une échéance serrée, un manager qui demande des mises à jour - les gens commencent à sauter des étapes. Pas parce qu'ils le veulent, mais parce qu'il n'y a pas de checklist claire à suivre.

Un modèle de déploiement résout ce problème. Ce n'est pas un document bureaucratique. C'est un filet de sécurité.

Ce que fait un modèle de déploiement

Un modèle de déploiement est une liste d'étapes qui doivent s'exécuter à chaque fois que vous poussez une nouvelle version de votre application vers n'importe quel environnement. Il ne vous dit pas comment faire votre travail. Il vous dit quoi ne pas oublier.

Le modèle fonctionne pour les API backend, les applications web et les workers en arrière-plan. Les détails techniques diffèrent - une équipe utilise des images Docker, une autre des binaires compilés - mais la structure reste la même. Cette structure comporte quatre phases : build et vérification, déploiement en staging, déploiement en production, et préparation d'un plan de rollback.

Le diagramme ci-dessous montre les quatre phases et comment elles se connectent, y compris la boucle de rétroaction lorsqu'une phase échoue.

flowchart TD A[Build et Vérification] -->|succès| B[Déploiement en Staging] A -->|échec| A B -->|succès| C[Déploiement en Production] B -->|échec| A C -->|succès| D[Plan de Rollback] C -->|échec| D D -->|rollback déclenché| A D -->|pas de rollback| E[Déploiement Terminé]

Phase Un : Build et Vérification

Avant que votre code n'aille où que ce soit, vous devez prouver qu'il s'exécute réellement. C'est la phase où la plupart des équipes ont déjà de l'automatisation, mais le modèle s'assure que rien n'est oublié.

Les étapes sont simples :

Voici un workflow GitHub Actions qui implémente la Phase Un pour une application Node.js :

name: Build and Verify
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm test
      - run: npm run build
      - name: Push Docker image
        run: |
          docker build -t myapp:${{ github.sha }} .
          docker tag myapp:${{ github.sha }} registry.example.com/myapp:${{ github.sha }}
          docker push registry.example.com/myapp:${{ github.sha }}

Ce workflow se déclenche à chaque push sur main, exécute les tests, construit l'application et pousse l'image Docker vers un registre. Si une étape échoue, le déploiement s'arrête automatiquement.

  • Récupérez le code depuis la bonne branche. Pas celle que vous pensez être correcte. Celle que vous avez réellement vérifiée.
  • Exécutez le processus de build. Cela produit l'artefact - une image Docker, un fichier JAR, un binaire compilé, selon votre stack.
  • Exécutez les tests unitaires et d'intégration. Ils confirment que le code se comporte comme prévu et que les pièces s'emboîtent.
  • Vérifiez les erreurs et les avertissements qui stopperaient le processus. Un build réussi avec des avertissements reste un build réussi, mais certains avertissements signalent de vrais problèmes.
  • Poussez l'artefact vers un registre accessible par vos environnements cibles. Si l'artefact n'est pas stocké, vous ne pouvez pas le déployer plus tard.

Si une étape de cette phase échoue, le déploiement s'arrête. Vous corrigez le code et recommencez. Aucune exception.

Phase Deux : Déploiement en Staging

Le staging est votre espace de répétition. Il reflète la production aussi fidèlement que possible, mais les vrais utilisateurs n'y touchent jamais. C'est là que vous attrapez les problèmes que les tests ne peuvent pas trouver - décalages de configuration, bugs spécifiques à l'environnement, problèmes d'intégration avec des services qui n'existent que dans des configurations proches de la production.

Les étapes ici incluent :

  • Tirez l'artefact depuis le registre. Utilisez exactement le même artefact qui a passé la phase un.
  • Déployez dans l'environnement de staging. Cela devrait utiliser le même mécanisme de déploiement que vous utiliserez en production.
  • Exécutez des tests de smoke. Ce sont des vérifications rapides qui confirment que l'application répond aux requêtes, se connecte à sa base de données et communique avec ses dépendances.
  • Vérifiez les logs pour des erreurs inattendues. Une application saine produit des logs prévisibles. Tout ce qui est inhabituel mérite d'être investigué.
  • Exécutez des tests d'intégration qui nécessitent un environnement complet. Certains tests n'ont de sens que lorsque tout le système est en cours d'exécution.

Si tout semble bon, vous passez à la phase suivante. Si quelque chose casse, vous revenez à la phase un, corrigez le code, reconstruisez et redéployez en staging.

Phase Trois : Déploiement en Production

C'est la phase critique. Les vrais utilisateurs dépendent de votre application. Les erreurs ici affectent le travail réel.

Le déploiement en production doit être progressif. Le déploiement blue-green, les canary releases ou les rolling updates fonctionnent tous. L'essentiel est que vous ne remplaciez pas tout à la fois.

Les étapes sont :

  • Confirmez qu'aucun autre déploiement n'est en cours. Deux déploiements simultanés créent le chaos.
  • Tirez le même artefact qui a passé le staging. Ne reconstruisez pas. Utilisez l'artefact vérifié.
  • Déployez en utilisant votre stratégie choisie. Si vous utilisez des canary releases, commencez avec un petit pourcentage du trafic.
  • Surveillez les métriques : temps de réponse, taux d'erreur, utilisation CPU, consommation mémoire, débit des requêtes. Ces chiffres vous indiquent si la nouvelle version est saine.
  • Exécutez des health checks et des tests de smoke après le déploiement. Ils confirment que l'application sert correctement le trafic.

Si les métriques semblent mauvaises, n'attendez pas. Déclenchez le rollback.

Phase Quatre : Le Plan de Rollback

Chaque déploiement a besoin d'un moyen de revenir en arrière. Pas une idée vague de revenir en arrière. Un plan concret écrit avant le début du déploiement.

Le plan de rollback répond à trois questions :

  • Quand rollbacker ? Définissez le déclencheur. Par exemple : le taux d'erreur dépasse 5 %, le temps de réponse augmente de 50 %, ou un endpoint critique cesse de répondre.
  • Comment rollbacker ? Spécifiez le mécanisme. Cela peut être rediriger le trafic vers la version précédente, redéployer l'ancien artefact, ou exécuter un script d'inversion de migration de base de données.
  • Qui décide ? Nommez la personne ou le rôle autorisé à appeler le rollback. En cas d'incident, attendre un consensus fait perdre du temps.

Écrivez le plan de rollback. Partagez-le avec l'équipe. Obtenez un accord avant de commencer le déploiement en production.

Checklist pratique pour le déploiement d'application

Voici une courte checklist que vous pouvez adapter pour votre équipe. Elle n'est pas exhaustive, mais elle couvre l'essentiel.

Build et Vérification

  • Code récupéré depuis la branche vérifiée
  • Build réussi
  • Tests unitaires et d'intégration passés
  • Artefact poussé vers le registre

Déploiement en Staging

  • Artefact tiré depuis le registre
  • Déploiement terminé sans erreur
  • Tests de smoke passés
  • Logs sans erreurs inattendues

Déploiement en Production

  • Aucun déploiement concurrent en cours
  • Artefact du staging utilisé
  • Stratégie de déploiement progressif appliquée
  • Métriques surveillées pendant 10 à 15 minutes
  • Health checks passés

Plan de Rollback

  • Déclencheur de rollback défini
  • Mécanisme de rollback spécifié
  • Décideur identifié
  • Plan partagé et approuvé avant le déploiement

Adaptez le modèle à votre équipe

Une équipe qui débute peut utiliser une version simple : build, déploiement en staging, déploiement en production, rollback. Une équipe mature peut ajouter des scans de sécurité, des tests de performance ou des portes d'approbation à chaque phase.

L'important n'est pas le nombre d'étapes que vous incluez. C'est que vous utilisiez le modèle de manière cohérente. Un modèle stocké dans un wiki que personne ne lit est inutile. Un modèle intégré dans votre pipeline de déploiement, revu avant chaque release et mis à jour quand vous apprenez quelque chose de nouveau - c'est ce qui rend les déploiements plus sûrs.

Ce qu'il faut retenir

Les modèles de déploiement existent parce que la mémoire n'est pas fiable, surtout sous pression. Écrivez les étapes. Partagez-les. Utilisez-les à chaque fois. Quand quelque chose tourne mal, vous saurez exactement quoi faire - et tout le monde dans votre équipe aussi.