wp-ship

Étape 7 : Ship

Objectif : le staging reflète le site live, chaque déploiement est routinier, le jour du lancement dispose d'un rollback, et la première semaine est surveillée.

Le propriétaire exécute les déploiements. Les agents préparent, vérifient et expliquent. Ils ne se connectent pas en SSH aux serveurs, n'exécutent pas deploy-safe.sh, ne modifient pas le DNS et ne touchent pas à Cloudflare sauf si le propriétaire demande cette action précise. deploy-safe.sh nécessite un terminal et un identifiant de commit tapé, donc un agent ne peut pas le terminer seul.

Étapes

1. Staging (references/deploy-and-launch.md, « Staging ») : son propre dossier et sa propre base de données sur l'hôte live, WP_ENVIRONMENT_TYPE=staging, derrière Cloudflare Access, une boîte de réception test pour les demandes de contact.
2. Durcir chaque serveur avec le docs/reference/DEPLOY_HARDENING.md du projet. Enregistrer les résultats dans docs/reference/SECURITY_PRELAUNCH.md.
3. Edge : paramètres Cloudflare depuis references/cloudflare-edge.md. Avant d'activer le proxy devant un ancien hôte, tester : certains hôtes limitent le débit par IP et bloqueront Cloudflare.
4. Déployer le code, propriétaire uniquement :
   • remplir deploy/targets.conf à partir de l'exemple ;
   • exécuter scripts/deploy-safe.sh <commit> --target staging --dry-run, lire la liste des changements, puis relancer sans --dry-run ;
   • le premier exécution sur un serveur qui contient déjà du code nécessite --assume-live <commit>.
5. Déployer le contenu séparément.
   • Le code ne transporte jamais les prix, les pages ou les textes légaux.
   • Enregistrer chaque modification sous docs/data/content-changes/<date>-<sujet>.json (valeurs avant et après par champ).
   • L'appliquer avec scripts/apply-content-change.sh <fichier> --target staging (dry run), puis --apply.
   • Après tout import ou déplacement de base de données, exécuter scripts/check-emoji.sh --target <env>.
6. Audit de lancement : exécuter l'agent launch-auditor sur le staging, corriger ce qui échoue, et le relancer jusqu'à ce qu'il réussisse.
7. Plan de bascule. Le rédiger à partir de references/deploy-and-launch.md, « Cutover ». Le propriétaire approuve la date et l'heure, ainsi que le partenaire commercial si le site prend déjà des réservations.
8. Mise en production : déployer sur le live, exécuter launch-auditor sur le live, soumettre le sitemap à Search Console, envoyer une vraie demande de test à la vraie boîte de réception.
9. Surveiller pendant 7 jours : erreurs, 404 (ajouter des redirections), boîte de réception des formulaires, analytics, couverture Search Console.

Porte (cocher dans SITE_STATUS.md)

• Staging derrière Access, noindex, courrier protégé
• Durcissement appliqué et enregistré
• Déploiement sécurisé vers le staging ; test de fumée vert
• launch-auditor RÉUSSI sur le staging, puis sur le live
• Plan de bascule approuvé (date, rollback, courrier/MX vérifié)
• Surveillance de 7 jours effectuée

Incidents qui ont façonné ces règles

• Un agent a modifié les prix en live, publié des conditions générales rédigées par IA et déployé une fonctionnalité sans révision, et son rapport a omis le déploiement. Depuis : les déploiements proviennent uniquement de commits fusionnés, via le script, tapés par un humain, et les clés SSH de production demandent une confirmation à chaque utilisation.
• Le formulaire de contact sur le staging publiait vers un service de formulaire tiers avec une clé test, donc les demandes allaient dans une boîte de réception test. Avant le lancement, envoyer une vraie demande sur le live et vérifier qu'elle arrive.
• Les analytics web en mode « allégé » ne comptaient pas les visiteurs européens pendant des semaines, ce qui a masqué les marchés principaux. Vérifier les réglages le jour 1.
• Un long déploiement (39 commits) s'est arrêté sur un SIGPIPE de git log | head sous pipefail. Le script capture désormais la sortie d'abord.
• Un import de base de données serveur a transformé les emoji en ????. Exécuter check-emoji.sh après chaque import.