Déploiement : l'action active de placer un artefact dans un environnement

Vous avez construit votre application, empaqueté en artefact et stocké dans un dépôt. Et ensuite ? L'artefact qui dort dans un dépôt n'est qu'un fichier. Il ne devient utile que lorsqu'il est placé dans un environnement et qu'il tourne réellement. Cette action de placement et d'exécution, les ingénieurs l'appellent le déploiement.

Le déploiement n'est pas un état passif. C'est une action active. Avant le déploiement, votre environnement de staging exécute la version 1.1.0. Après le déploiement, il exécute la version 1.2.0. Quelque chose a changé dans cet environnement. Quelqu'un ou quelque chose a pris l'artefact, l'a déplacé sur le bon serveur et l'a démarré.

Ce qui se passe réellement pendant un déploiement

Lorsqu'une équipe décide d'envoyer la version 1.2.0 en staging, une série d'étapes concrètes doit se produire. Quelqu'un récupère l'artefact depuis le dépôt. Il le transfère vers le serveur de staging. Il arrête l'ancien processus, démarre le nouveau et vérifie qu'il tourne. L'environnement a désormais un nouvel état.

Voici un exemple concret de ces étapes sous forme de commandes shell :

scp myapp-v1.2.0.jar user@staging-server:/opt/myapp/ && \
ssh user@staging-server "systemctl stop myapp && \
  cp /opt/myapp/myapp-v1.2.0.jar /opt/myapp/current.jar && \
  systemctl start myapp"

C'est pourquoi le déploiement est différent du simple stockage de fichiers. Vous pouvez avoir un dépôt d'artefacts parfait avec toutes les versions jamais construites, mais tant que ces artefacts ne sont pas placés dans des environnements et exécutés, rien n'a été livré. Le déploiement est le pont entre « nous l'avons construit » et « il tourne quelque part ».

Le diagramme de séquence suivant illustre la séparation entre déploiement et mise à disposition :

sequenceDiagram participant AR as Registre d'artefacts participant DT as Outil de déploiement participant S as Serveur participant LB as Équilibreur de charge DT->>AR: Récupérer artefact v1.2.0 DT->>S: Transférer artefact DT->>S: Arrêter ancien processus (v1.1.0) DT->>S: Démarrer nouveau processus (v1.2.0) DT->>S: Vérifier la santé S-->>DT: Sain Note over DT,LB: Déploiement terminé DT->>LB: Basculer le trafic vers v1.2.0 Note over DT,LB: Mise à disposition effectuée

La question qui vient naturellement est : le déploiement signifie-t-il que les utilisateurs peuvent immédiatement utiliser la nouvelle version ? Pas nécessairement. Le déploiement et la mise à disposition (release) sont deux concepts différents, même si les équipes les réalisent souvent ensemble.

Déploiement versus mise à disposition

Le déploiement est une action technique. Vous placez un artefact dans un environnement et l'exécutez. La mise à disposition concerne l'accès. Elle répond à la question : quand les utilisateurs commencent-ils réellement à utiliser la nouvelle version ?

Imaginez que votre équipe déploie la version 1.2.0 en production à 2h00 du matin. Les serveurs de production exécutent désormais la nouvelle version, mais l'équipe ne dirige pas encore le trafic utilisateur vers elle. Le déploiement a eu lieu. La mise à disposition, non. Les utilisateurs sont toujours sur l'ancienne version. L'équipe peut vérifier que la nouvelle version est saine avant d'ouvrir la porte.

Imaginez maintenant le scénario inverse. L'équipe déploie en production et dirige immédiatement tous les utilisateurs vers la nouvelle version. Dans ce cas, le déploiement et la mise à disposition se produisent en une seule étape. Les deux approches sont valables, mais comprendre la différence vous donne des options.

Pourquoi cette séparation est-elle importante ? Parce que le déploiement peut échouer. Quand cela arrive, vous devez savoir comment ramener l'environnement à son état précédent. Cette action s'appelle le rollback. Le rollback est essentiellement un déploiement de l'ancienne version dans le même environnement. Si votre équipe sait seulement « pousser la nouvelle version » sans comprendre que le déploiement est une action réversible, vous aurez du mal quand les choses tourneront mal.

Le déploiement n'est pas toujours fluide

Même avec une planification minutieuse, les déploiements peuvent rencontrer des problèmes. Le serveur peut manquer d'espace disque. Un fichier de configuration peut contenir une faute de frappe. L'artefact téléchargé depuis le dépôt peut être corrompu. Un problème réseau peut provoquer un timeout pendant le transfert.

C'est pourquoi chaque déploiement nécessite une vérification. Après que l'artefact a été placé et exécuté, quelqu'un ou quelque chose doit vérifier que l'environnement est réellement sain. L'application répond-elle aux requêtes ? Les logs sont-ils propres ? Les métriques attendues sont-elles dans la plage normale ?

La vérification peut être automatisée ou manuelle, mais elle doit exister. Un déploiement qui se termine sans vérification revient à espérer que rien ne s'est mal passé. L'espoir n'est pas une stratégie de déploiement.

Les implications pratiques

Une fois que vous considérez le déploiement comme une action active plutôt qu'un état passif, plusieurs choses deviennent plus claires.

Premièrement, le déploiement est répétable. Si vous pouvez déployer la version 1.2.0 aujourd'hui, vous devriez pouvoir déployer à nouveau la version 1.2.0 demain, dans le même environnement, avec le même résultat. Si ce n'est pas le cas, votre processus de déploiement comporte des étapes cachées ou des dépendances.

Deuxièmement, le déploiement est réversible. Si la version 1.2.0 cause des problèmes, vous devriez pouvoir déployer la version 1.1.0 dans le même environnement. C'est le rollback. Si le rollback est pénible ou risqué, votre processus de déploiement a besoin d'être amélioré.

Troisièmement, le déploiement est vérifiable. Vous devriez savoir, dans un délai raisonnable, si le déploiement a réussi ou échoué. Pas seulement si le script s'est exécuté sans erreur, mais si l'application fonctionne réellement correctement dans cet environnement.

Une checklist simple pour le déploiement

Avant de considérer un déploiement comme terminé, passez en revue ces points :

  • L'artefact a-t-il été placé dans le bon environnement ?
  • La nouvelle version tourne-t-elle réellement et accepte-t-elle du trafic ?
  • Les vérifications de santé de base passent-elles (codes de réponse, latence, taux d'erreur) ?
  • Pouvez-vous confirmer que l'ancienne version ne tourne plus (sauf en cas de déploiement progressif) ?
  • Savez-vous comment effectuer un rollback si nécessaire, et ce chemin de rollback a-t-il été testé ?

Cette checklist n'est pas exhaustive, mais elle couvre le minimum. Chaque équipe devrait l'enrichir en fonction de son propre environnement et des caractéristiques de son application.

Ce qu'il faut retenir

Le déploiement est le moment où votre artefact cesse d'être un fichier et devient un service en cours d'exécution. C'est une action active, répétable, réversible et vérifiable. Séparer le déploiement de la mise à disposition vous donne le contrôle sur le moment où les utilisateurs voient les changements. Vérifier chaque déploiement vous évite de découvrir les problèmes après vos utilisateurs.

La prochaine fois que votre équipe dit « nous avons déployé », demandez : avons-nous réellement placé l'artefact et vérifié qu'il tourne ? Ou avons-nous simplement appuyé sur un bouton en espérant que ça marche ? La réponse vous dira à quel point votre processus de déploiement est mature.