Documentation · Chapitre 18

Répéter le déploiement avant que les utilisateurs en dépendent.

Cet atelier déploie en staging, vérifie la santé, simule une release cassée et restaure la précédente.

Chaque leçon part du problème, explique le mécanisme puis propose une vérification concrète.

OBJECTIF DE LA LEÇON

Ce que vous saurez faire

Répéter un déploiement staging et sa récupération en conservant assez de preuves pour la production.

Préparer staging

Créez un profil staging avec PHP, extensions, racine Web et famille de base proches de la production.

phpaml — zsh
aml build
aml deploy:check staging
aml deploy staging --dry-run
aml deploy staging
curl -f https://staging.example.com/health

Déployer et tester

Construisez une fois, check, dry-run, deploy, status et smoke tests depuis l’extérieur.

Casser, récupérer et consigner

Publiez un health volontairement cassé en staging, prouvez rollback puis notez durée, commandes, checksum et observations.

POINT DE CONTRÔLE

Avant de continuer

Combien de temps la détection et le retour ont-ils réellement pris, et quelle preuve confirme le rétablissement ?

EN RÉSUMÉ

Ce qu’il faut retenir

  • Une release est un artefact immuable et identifié.
  • Build exclut les secrets et publie une preuve d’intégrité.
  • Check et dry-run précèdent toute modification distante.
  • Activation atomique et rollback répété réduisent le risque.