Déployer un service : manuel, scripté ou automatisé

Déployer un service, c'est l'installer et le configurer dans l'environnement de production, y reprendre les données utiles, le rendre accessible aux utilisateurs, puis vérifier qu'il fonctionne avant de l'annoncer. On peut le faire à la main en suivant une procédure, par un script rejouable, ou par un pipeline qui enchaîne tout automatiquement ; et on peut basculer tous les utilisateurs d'un coup ou progressivement. Ce chapitre compare ces façons de faire, puis traite la reprise des données, le déploiement sur les postes, les tests de fumée et le journal de mise en production.

Ce que comprend un déploiement

« Déployer » ne veut pas dire « copier le programme sur le serveur ». Un déploiement complet enchaîne six familles d'actions, et un oubli dans l'une d'elles suffit à rater l'ouverture.

Trois façons de déployer

Ces trois façons ne s'opposent pas : on commence souvent par une procédure manuelle bien écrite, on en fait un script quand on la répète, puis on branche ce script sur un pipeline. Le point commun indispensable est une procédure écrite et versionnée : sans elle, personne d'autre ne peut déployer, et personne ne sait ce qui a été fait.

La procédure manuelle : le mode opératoire

Un mode opératoire (ou procédure de déploiement, runbook en anglais) décrit chaque étape avec la commande exacte et le résultat attendu. Il est écrit pour être suivi par quelqu'un qui ne l'a pas rédigé. Extrait de celui de Prêt'Matos :

Les règles d'un bon mode opératoire : une action par ligne, la commande exacte à copier, le résultat attendu pour savoir si l'on peut continuer, et ce qu'il faut faire si ce n'est pas le cas (« si bdd n'est pas healthy après 2 minutes : lire docker compose logs bdd, puis appliquer le plan de retour arrière »). Les détails du fichier compose.yaml et du reverse proxy sont dans le cours Docker.

Le déploiement scripté

Un script transforme le mode opératoire en programme. Il n'oublie pas d'étape, ne fait pas de faute de frappe et peut être relu et testé en recette avant de servir en production. Un bon script de déploiement respecte six principes :

1. Il s'arrête à la première erreur (set -euo pipefail en Bash, $ErrorActionPreference = 'Stop' en PowerShell) au lieu de continuer sur un état cassé.
2. Il reçoit la version à déployer en paramètre, et la vérifie : on ne déploie jamais « la dernière », mais une version précise, celle qui a été recettée.
3. Il est idempotent autant que possible : le relancer ne casse rien et ne crée pas de doublon. C'est la philosophie d'Ansible, qui décrit l'état voulu plutôt que les commandes à taper (l'idempotence).
4. Il vérifie le résultat à la fin (une route de santé, un test de fumée) et renvoie un code d'erreur si le service ne répond pas.
5. Il sait revenir en arrière : il mémorise la version précédente et sait la redémarrer.
6. Il ne contient aucun secret : les mots de passe sont dans des fichiers de secrets ou un coffre, hors du dépôt.

Le cours Intégration continue écrit un tel script, ligne par ligne, pour une application en conteneurs. Côté SISR, le même raisonnement s'applique à un script PowerShell qui crée les groupes et le partage d'un nouveau service, ou à Ansible pour configurer dix serveurs à l'identique (automatisation avec Ansible).

Le déploiement continu

Le déploiement continu (la partie CD de CI/CD) automatise toute la chaîne : à chaque modification validée, le pipeline construit l'application, lance les tests, publie l'image, la déploie en recette, puis en production après une approbation humaine. Les étapes de ce chapitre ne disparaissent pas : elles sont écrites dans le pipeline au lieu d'être faites à la main.

Pour une PME, le pipeline peut s'arrêter à la recette, et la production se déployer par le script lancé à la main : c'est ce que fait Sorbier pour la première version de Prêt'Matos, en attendant d'avoir confiance dans la chaîne. Les détails sont dans le cours Intégration continue.

Les stratégies de bascule

Une fois le service installé, il reste à décider comment les utilisateurs passent de l'ancien fonctionnement au nouveau. Le choix dépend du risque, du nombre d'utilisateurs et de la possibilité de faire tourner les deux en même temps.

Pour un service interne de PME, la bascule directe ou par vagues couvre presque tous les cas. Le bleu-vert et le canari supposent une infrastructure que peu de PME ont : le cours Intégration continue les met en œuvre.

Reprendre les données de l'ancien outil

La reprise de données (ou migration de données) fait passer dans le nouveau service les informations utiles de l'ancien : un tableur, un autre logiciel, des dossiers. Elle se prépare comme un mini-projet, en six temps.

1. Inventorier : quelles données existent, lesquelles sont utiles, lesquelles on abandonne ou on archive.
2. Nettoyer : doublons, fautes de frappe, champs mal remplis.
3. Transformer : faire correspondre les colonnes de l'ancien outil aux champs du nouveau, convertir les formats (dates, codes).
4. Importer, d'abord en recette, au moins deux fois, puis en production.
5. Contrôler : comptages, totaux, échantillon vérifié par un utilisateur.
6. Geler l'ancien outil au moment de la bascule, en le gardant en lecture seule pour la consultation et le retour arrière.

Pour Prêt'Matos, le tableur de la logistique contient trois listes. La reprise donne :

Le contrôle compare ce qui devait être importé et ce qui l'a été, par une requête simple sur la base après l'import :

SELECT 'materiel' AS donnee, COUNT(*) AS lignes FROM materiel
UNION ALL
SELECT 'reservations a venir', COUNT(*) FROM reservation WHERE statut = 'reservee'
UNION ALL
SELECT 'prets en cours', COUNT(*) FROM reservation WHERE statut = 'sortie';

Le résultat attendu est 24, 17 et 5. Un écart arrête la bascule : on cherche, on corrige, ou l'on applique le retour arrière. Enfin, Nadia vérifie un échantillon : son planning de la semaine dans l'application doit être identique au tableur (les requêtes d'agrégat en SQL).

Déployer côté postes

Beaucoup de services demandent aussi une action sur les postes : un favori dans le navigateur, un lecteur réseau, un agent, un logiciel client, un certificat. À la main, sur 16 postes, c'est long et inégal ; on le fait par les outils de déploiement.

Le cours Déploiement de postes détaille ces outils. Pour Prêt'Matos, il suffit d'un favori « Prêt de matériel » déployé dans Edge par stratégie de groupe, et d'un lien sur la page d'accueil de l'intranet.

Les tests de fumée et la vérification

Un test de fumée (smoke test) est une vérification rapide, juste après le déploiement, que l'essentiel fonctionne : la page répond, la connexion marche, une écriture en base réussit. S'il échoue, inutile d'aller plus loin : on corrige tout de suite ou l'on applique le retour arrière. Il se fait avant d'annoncer l'ouverture.

Une partie des tests de fumée s'automatise. Ce script, versionné avec le service, vérifie la page, l'API, la redirection vers HTTPS et la date de fin du certificat :

#!/usr/bin/env bash
# Tests de fumée de Prêt'Matos, lancés juste après un déploiement.
# Usage : ./tests-fumee.sh https://pretmatos.ad.sorbier.example
set -uo pipefail

BASE="${1:?Usage : tests-fumee.sh <adresse https du service>}"
HOTE="${BASE#https://}"
ECHECS=0

verifier() {   # verifier "<libellé>" <commande> [arguments…]
  local libelle="$1"
  shift
  if "$@" > /dev/null 2>&1; then
    echo "OK  $libelle"
  else
    echo "KO  $libelle"
    ECHECS=$((ECHECS + 1))
  fi
}

redirige_vers_https() {
  local entetes
  entetes=$(curl --silent --head --max-time 10 "http://$HOTE/")
  grep -qi '^location: https://' <<< "$entetes"
}

certificat_valable_30_jours() {
  local certificat
  certificat=$(openssl s_client -connect "$HOTE:443" -servername "$HOTE" < /dev/null 2> /dev/null)
  openssl x509 -noout -checkend 2592000 <<< "$certificat"
}

verifier "page d'accueil"                curl --fail --silent --max-time 10 "$BASE/"
verifier "route de santé de l'API"       curl --fail --silent --max-time 10 "$BASE/api/sante"
verifier "redirection HTTP vers HTTPS"   redirige_vers_https
verifier "certificat valable 30 jours"   certificat_valable_30_jours

if [ "$ECHECS" -eq 0 ]; then
  echo "Tests de fumée : tout est vert."
else
  echo "Tests de fumée : $ECHECS échec(s). Ne pas ouvrir le service." >&2
  exit 1
fi

Le reste se vérifie à la main, avec un compte de test : se connecter avec un compte du domaine, créer puis annuler une réservation, déclencher un rappel de test, vérifier que la sauvegarde de la nuit est programmée. Puis un utilisateur référent fait le tour de ses écrans habituels : c'est l'étape 6 du plan, la vérification par Nadia.

Le journal de mise en production

Le journal de mise en production note, pendant l'opération, l'heure, l'action, le résultat et chaque écart au plan. Il sert pendant l'opération (où en est-on ?), juste après (la décision s'appuie dessus), et longtemps après (que s'est-il passé ce jour-là, en cas d'incident trois semaines plus tard ?).

Remarque la ligne 5 bis : l'écart est corrigé et reporté dans le dépôt et dans le mode opératoire. Une correction faite seulement sur le serveur serait perdue au prochain déploiement.

Exercices

#!/usr/bin/env bash
cd /srv/pretmatos
docker compose pull
docker compose up -d
echo "Déploiement réussi"