Chapitre 11.6 — Migrations & déploiement

⏱️ TL;DR — Un workflow pro sépare local → staging → production, versionne le code (Git, avec Composer pour les dépendances), et gère la base + les médias séparément du code. Le déploiement du code est automatisable (Git/CI, rsync, ou l’API de l’hébergeur) ; la base, elle, ne se « déploie » pas comme du code (elle contient des données de prod) — on gère les changements de schéma via l’upgrade du plugin et on remonte rarement la base (sauf init). Les secrets restent hors du dépôt (env). Objectif : déployer sans casser, de façon réversible.

🎯 Objectifs

• Structurer un workflow local/staging/prod.
• Versionner correctement (code oui, base/uploads non).
• Gérer les changements de schéma (upgrade routine).
• Déployer proprement (et pouvoir revenir en arrière).

1. Trois environnements

• Local (ch. 4.1) : développement, tests.
• Staging : copie proche de la prod (mêmes versions, données récentes) pour valider avant mise en ligne (ch. 2.7).
• Production : le site public.

Le code remonte : local → staging → prod. Les données (base, uploads) redescendent souvent (prod → staging) pour tester sur des données réalistes.

⚠️ Piège n°1 — développer/tester en prod. Toute modification se valide d’abord en staging (ch. 2.7). Déployer directement en prod, c’est jouer avec les visiteurs et les données réelles.

2. Versionner : quoi, et quoi pas

Beaucoup d’équipes pros gèrent tout le projet avec Composer (le cœur + les plugins tiers comme dépendances, via wpackagist), ne versionnant que leur code + le manifeste. C’est le workflow qui rapproche WordPress d’un projet moderne (ch. 4.4).

⚠️ Piège n°2 — committer les secrets ou les uploads. wp-config.php (identifiants/sels) et uploads/ (gros, généré) n’ont rien à faire dans Git (ch. 4.2/4.4). Secrets = variables d’environnement / gestionnaire de secrets ; uploads = synchronisés séparément (rsync/S3).

3. La base : pas un « déploiement » comme le code

Le code peut être écrasé/remplacé ; la base de prod contient des données réelles (commandes, contenus, users) qu’on ne remplace pas par celle de dev. Donc :

• On ne « pousse » pas la base de dev/staging en prod (sauf initialisation), sous peine d’écraser les données réelles.
• Les changements de schéma (nouvelle table/colonne d’un plugin) se font via la routine d’upgrade du plugin, déclenchée par un numéro de version (comme les migrations) :

add_action( 'plugins_loaded', function () {
    $installed = get_option( 'wpr_db_version' );
    if ( $installed !== WPR_DB_VERSION ) {
        wpr_run_upgrades( $installed ); // dbDelta, migrations de données…
        update_option( 'wpr_db_version', WPR_DB_VERSION );
    }
} );

Ainsi, le schéma évolue par code (versionné, reproductible), tandis que les données de prod restent en place. C’est l’équivalent des migrations d’un ORM.

⚠️ Piège n°3 — écraser la base de prod. Importer un dump de staging en prod détruit les données créées entre-temps (nouvelles commandes, comptes…). Les changements de structure passent par une routine d’upgrade idempotente ; les données de prod ne se remplacent pas.

4. Déployer le code

• Git-based : push → CI (ch. 11.4) → déploiement (l’hébergeur tire le dépôt, ou un runner fait un composer install + build + rsync/SSH).
• Build : compiler les assets (blocs, ch. 8.2 ; npm run build) avant déploiement ; ne pas déployer node_modules.
• Atomique/réversible : idéalement un déploiement atomique (symlink vers la nouvelle release) permettant un rollback instantané.
• Après déploiement : purger les caches (ch. 11.2), jouer les upgrades, vérifier (smoke test).

5. Checklist de mise en ligne

1. Sauvegarde de la prod (code + base + uploads) — filet.
2. Valider en staging (données proches de la prod).
3. Déployer le code (build inclus), jouer la routine d’upgrade.
4. search-replace des URLs si changement de domaine (ch. 2.6, wp search-replace).
5. Purger les caches, vérifier les permaliens (flush si CPT).
6. Smoke test : pages clés, formulaires, paiement (Woo), HTTPS, e-mails.
7. Surveiller les logs/erreurs après mise en ligne.

💡 Pour un dev React — Le principe est identique à vos déploiements : code versionné + build en CI + déploiement atomique + rollback, secrets en env, assets buildés. La différence WordPress est la base stateful de prod : on ne la traite pas comme du code (pas de « push » de la DB), on fait évoluer le schéma par migrations (routine d’upgrade) en préservant les données. Séparer « code (déployable) » et « données (préservées) » est la clé d’un déploiement WordPress sûr.

✏️ Exercices

1. Pourquoi ne « pousse »-t-on pas la base de staging vers la prod (hors init) ?
2. Comment fait-on évoluer le schéma d’un plugin sans écraser les données de prod ?
3. Citez trois choses à ne pas versionner dans Git pour un projet WordPress.

🧠 Quiz de révision

Chapitre suivant : Accessibilité & i18n avancée.