La gestion des changements de schéma de base de données dans les environnements WordPress est souvent une tâche longue et sujette aux erreurs. Une seule requête SQL mal placée ou une modification de base de données oubliée est une action qui brise le site pendant le déploiement. De plus, les actions telles que les scripts SQL manuels et les modifications directes manquent de contrôle de version, de pistes d’audit et de coordination entre les environnements.
L’utilisation de Radicle de Roots (spécifiquement Acorn) est une solution, car elle apporte les migrations Laravel dans WordPress. Vous obtenez des modifications de base de données contrôlées par version qui se déploient en même temps que votre code, un suivi automatique des modifications exécutées et la possibilité de revenir en arrière sur les modifications de schéma si nécessaire.
Lorsque vous combinez cela avec l’infrastructure et les outils de Kinsta, vous obtenez un moyen d’automatiser l’exécution de la migration pendant les déploiements.
Pourquoi les modifications de la base de données de WordPress ont besoin d’un contrôle de version
Les modifications manuelles de la base de données traitent les changements de schéma comme des opérations ponctuelles plutôt que comme du code versionné. Par exemple, vous exécutez une requête SQL pour ajouter une table personnalisée, vous exécutez une instruction ALTER TABLE pour ajouter des colonnes, ou vous vous fiez aux crochets d’activation des extensions pour gérer les mises à jour. Ces solutions fonctionnent dans un premier temps, mais elles s’effondrent lorsque vous gérez plusieurs environnements ou que vous travaillez avec une équipe.
Les environnements de staging commencent souvent à diverger des environnements locaux lorsque vous oubliez de documenter les petites modifications (comme l’ajout d’une colonne à la base de données locale), ce qui entraîne également l’échec des déploiements en production. Cela signifie également qu’il n’y a pas de piste d’audit.
Les migrations Laravel sont un bon moyen d’éliminer ces échecs de coordination car elles traitent les modifications de la base de données comme du code versionné qui vit dans votre dépôt Git. Ce code est déployé avec votre application et s’exécute dans le même ordre dans tous les environnements.
Comment les migrations Laravel fonctionnent dans WordPress avec Acorn
Les migrations Laravel sont des fichiers PHP qui définissent les changements de schéma de base de données par deux méthodes : up() applique les changements et down() les inverse. Chaque fichier de migration reçoit un préfixe d’horodatage qui détermine l’ordre d’exécution. Roots’ Acorn apporte ce système de migration (et plus encore) à WordPress sans nécessiter une installation complète de Laravel.
Le système de migration suit les changements qui ont été exécutés en utilisant une table migrations dans votre base de données WordPress. Lorsque vous exécutez wp acorn migrate, Acorn effectue quelques tâches :
- Vérifier la table pour identifier les migrations en cours.
- Exécuter les tables dans l’ordre chronologique en se basant sur les horodatages.
- Enregistrer chaque migration réussie.
Ce suivi empêche les migrations de s’exécuter plusieurs fois et vous permet de savoir exactement quelles modifications de schéma ont été appliquées à un environnement donné.
Acorn intègre le constructeur de schémas de Laravel, qui fournit une syntaxe PHP fluide pour créer et modifier les tables de la base de données. Au lieu d’écrire du code SQL brut, vous utilisez des méthodes telles que $table->string('key')->unique() ou $table->json('value')->nullable(). Cette approche offre une syntaxe agnostique à la base de données, une sécurité de type et un code plus lisible que les instructions SQL avec des chaînes concaténées.
Créer et exécuter votre première migration
Vous créez des migrations via WP-CLI :
wp acorn make:migration create_app_settings_tableCela génère un nouveau fichier de migration dans le répertoire database/migrations/ avec l’horodatage actuel et le nom que vous avez spécifié :
<?php
use IlluminateDatabaseMigrationsMigration;
use IlluminateDatabaseSchemaBlueprint;
use IlluminateSupportFacadesSchema;
return new class extends Migration
{
public function up(): void
{
Schema::create('app_settings', function (Blueprint $table) {
$table->id();
$table->string('key')->unique();
$table->json('value')->nullable();
$table->string('group')->default('general');
$table->boolean('is_public')->default(false);
$table->text('description')->nullable();
$table->timestamps();
$table->index('group');
$table->index('is_public');
});
}
public function down(): void
{
Schema::dropIfExists('app_settings');
}
};La méthode up() crée la table avec des colonnes pour le stockage des paires clé-valeur, le regroupement des réglages et le suivi de la date de création ou de modification des entrées. Les index sur group et is_public améliorent les performances des requêtes. La méthode down() supprime complètement la table, ce qui vous permet d’inverser la migration.
Vous exécutez les migrations en attente à l’aide de la commande wp acorn migrate. Cette commande exécute toutes les migrations qui n’ont pas encore été exécutées, crée des tables et modifie le schéma de votre base de données. Vous pouvez vérifier quelles migrations ont été exécutées à l’aide de la commande wp acorn migrate:status. La sortie d’état affiche chaque fichier de migration avec des indicateurs indiquant s’il a été exécuté.
Lorsque vous devez annuler le dernier lot de migrations, vous utilisez la commande wp acorn migrate:rollback. Celle-ci exécute la méthode down() pour chaque migration du dernier lot afin d’annuler les modifications.
Vérification des migrations avec Database Studio
Après avoir exécuté les migrations, Database Studio de Kinsta (ou tout autre outil de base de données) vous permet de vérifier que les tables et les colonnes attendues existent avec la structure correcte. Vous accédez à Database Studio via le tableau de bord MyKinsta en naviguant vers n’importe quel site et en cliquant sur l’onglet Base de données :
La console SQL incluse vous permet de lancer des requêtes de vérification pour confirmer que vos migrations ont créé la structure attendue.
Après avoir créé la table app_settings, la requête DESCRIBE app_settings; vous permet de vérifier les colonnes. Elle renvoie la structure de la table en indiquant les noms, les types et les index des colonnes. Une autre requête : SELECT * FROM app_settings; vous permet de vérifier que la table accepte les insertions.
Le filtrage vous permet d’examiner des enregistrements ou des colonnes spécifiques sans écrire de requêtes SQL. Ici, vous cliquez sur les en-têtes de colonne pour trier, vous appliquez des filtres pour restreindre les résultats et vous exportez vos données :
Ces options d’exportation sont utiles avant de tester les procédures de retour en arrière.
Exécuter des migrations avec SSH et WP-CLI sur Kinsta
Kinsta inclut l’accès SSH et WP-CLI dans tous les plans. Cela signifie que vous exécutez des commandes de migration directement sur vos environnements de staging et de production sans aucune configuration supplémentaire.
Pour exécuter des migrations sur un environnement Kinsta, connectez-vous d’abord à celui-ci en utilisant SSH. Les identifiants se trouvent sur l’écran d’information de n’importe quel site dans MyKinsta :
Après vous être connecté et authentifié, naviguez jusqu’à la racine du document de votre site. Pour les sites Radicle, il s’agit du répertoire public. Ensuite, vous exécutez wp acorn migrate.
Le processus de migration affiche une sortie indiquant les migrations en cours et l’état d’achèvement de chacune d’entre elles. Cette méthode fonctionne également dans les environnements de production et de staging, car Acorn suit les migrations de manière indépendante dans la base de données de chaque environnement.
Tester les migrations dans les environnements de staging Kinsta
Les environnements de staging de Kinsta sont des espaces sûrs pour tester les migrations avant de les déployer en production, mais vous avez besoin d’un flux de travail fiable pour les tester. Une fois que vous avez vérifié les modifications apportées à la migration dans Database Studio, testez le rollback pour vous assurer que la méthode down() fonctionne correctement.
Pour cela, passez à votre environnement de staging dans MyKinsta, naviguez vers l’onglet Base de données et inspectez les tables que vos migrations ont créées ou modifiées.
Si vous découvrez des problèmes au cours des tests, la commande wp acorn migrate:rollback vous permet de revenir sur le dernier lot de migrations et d’apporter des corrections sans affecter la production. Vous pouvez ensuite modifier vos fichiers de migration, valider les modifications, déployer à nouveau la migration et effectuer un nouveau test.
La poussée sélective de Kinsta vous permet de déployer uniquement les changements que vous avez testés. Vous pouvez donc choisir de ne pousser que vos fichiers vers la production ou de pousser à la fois les fichiers et la base de données :
Pour les flux de migration, vous ne poussez généralement que les fichiers parce que les migrations s’exécutent sur la base de données de production existante plutôt que de l’écraser avec des données d’étape.
Flux de déploiement avec des migrations automatisées
Les flux de migration automatisés modifient le schéma de la base de données lors du déploiement du code, ce qui élimine les étapes manuelles et réduit les erreurs de déploiement. Vous y parvenez en ajoutant des commandes de migration à votre processus de déploiement, qu’il s’agisse de scripts SSH manuels, de l’automatisation des actions GitHub ou d’outils tels que Trellis de Roots.
Pour les déploiements manuels utilisant SSH, connectez-vous à votre environnement de production et naviguez jusqu’à la racine du document. Ensuite, exécutez les commandes suivantes dans l’ordre :
git pull origin main
composer install --no-dev
npm install && npm run build
wp acorn optimize
wp acorn migrate --forceLe drapeau --force indique à Acorn d’exécuter les migrations sans demande de confirmation, ce qui est essentiel pour les déploiements automatisés où vous ne pouvez pas interagir avec le terminal. L’exécution de cette commande après wp acorn optimize permet de s’assurer que le cache de l’application est frais avant l’exécution des migrations.
Si vous utilisez les actions GitHub pour le déploiement continu, vous automatisez les migrations dans votre fichier de flux de travail. Radicle inclut une configuration .github/workflows/deploy.yml que vous modifiez pour inclure une étape de migration après le processus de construction :
- name: Run migrations
run: |
ssh user@host -p port 'cd /path/to/site && wp acorn migrate --force'Le flux de déploiement se connecte via SSH, navigue vers votre répertoire de site et exécute la commande de migration.
Pour les déploiements utilisant Trellis, les migrations s’intègrent dans les crochets de déploiement. Vous incluez les éléments suivants en modifiant deploy-hooks/finalize-after.yml :
- name: Run Acorn migrations
command: wp acorn migrate --force
args:
chdir: "{{ deploy_helper.new_release_path }}"Cela permet d’exécuter les migrations après que Trellis a terminé les autres tâches de déploiement. Les migrations s’exécutent dans le répertoire de la nouvelle version, et Trellis gère le retour en arrière si le déploiement échoue.
Contrôle de la version des fichiers de migration avec Git
Les fichiers de migration se trouvent dans le répertoire database/migrations/ de la structure de votre projet Radicle. Ce répertoire fait partie de votre répertoire Git, ce qui signifie que les migrations voyagent avec votre code à travers le contrôle de version. Le flux de travail reflète le développement standard : créer des migrations localement, les livrer à une branche de fonctionnalité, et les fusionner à la branche principale après les avoir testées.
Le flux de validation des migrations suit un modèle cohérent :
git add database/migrations/2025_01_03_140000_create_app_settings_table.php
git commit -m "Add app_settings table migration"
git push origin feature-branchUne fois que vous avez examiné la migration, vous fusionnez la branche de fonctionnalités avec main, ce qui rend la migration disponible pour les déploiements en phase de staging et en production.
La commande wp acorn migrate:status vérifie que tous les environnements appliquent les mêmes migrations. Vous exécutez cette commande dans tous les environnements pour confirmer qu’ils sont synchronisés. Si un environnement affiche des migrations en attente, cela signifie qu’il a besoin d’un déploiement ou d’une migration manuelle pour rattraper son retard.
Stratégies de retour en arrière et sauvegardes des bases de données
Cependant, toutes les migrations ne sont pas entièrement réversibles. Alors que vous pouvez simplement supprimer une table pour annuler sa création, une migration qui supprime des données est une action permanente. Parfois, down() peut vous indiquer pourquoi un retour en arrière n’est pas possible :
public function down(): void
{
// This migration cannot be reversed as we're deleting data
Log::warning("Migration cannot be reversed - data permanently deleted");
}Il est bon de documenter ces limitations. Les sauvegardes automatisées de Kinsta constituent un filet de sécurité, il est donc également important de créer une sauvegarde manuelle avant d’exécuter une migration qui pourrait causer des problèmes :
Naviguez vers votre site, cliquez sur Sauvegardes, et générez une sauvegarde avec un nom descriptif. Si une migration provoque des problèmes inattendus dans la production, vous restaurez à partir de cette sauvegarde via MyKinsta.
Pour les retours de migration, vous ne restaurez que la base de données dans l’environnement de production. La restauration s’effectue en quelques minutes et ramène votre base de données à l’état exact capturé dans la sauvegarde.
Construire des flux de données fiables pour WordPress
Les migrations Laravel via l’implémentation d’Acorn par Radicle transforment ce qui est souvent une source d’anxiété en un processus prévisible et contrôlé par version. La combinaison des migrations en tant que code, des environnements de staging de Kinsta et de Database Studio pour la vérification crée un flux de travail qui vous permet de détecter les problèmes de schéma avant qu’ils n’atteignent la production.
En tant que tel, le développement moderne de WordPress qui inclut des outils tels que Radicle et Acorn signifie que vous n’avez pas à choisir entre l’écosystème de WordPress et les cadres d’outils professionnels. Le même schéma s’applique aux files d’attente Laravel, au templating Blade et aux commandes WP-CLI personnalisées via Acorn.
Si vous êtes prêt à adopter ce flux de travail, l’étape suivante consiste à établir des conventions de migration, telles que la définition de modèles de nommage pour les fichiers de migration, la documentation du processus et l’établissement d’exigences de test avant les fusions clés. L‘hébergement infogéré de Kinsta pour WordPress offre des outils de développement intégrés pour vous aider (tels que l’accès SSH, les environnements de staging et Database Studio) qui prennent en charge les flux de travail modernes, y compris les migrations Radicle et Acorn.
Joel est un développeur d'interfaces publiques qui travaille chez Kinsta en tant que rédacteur technique. Il est un enseignant passionné par l'open source et a écrit plus de 200 articles techniques, principalement autour de JavaScript et de ses frameworks.
