Lorsque vous combinez cela avec l’infrastructure et les outils de Kinsta, vous obtenez un moyen d’automatiser l’ex\u00e9cution de la migration pendant les d\u00e9ploiements.<\/p>\n
Pourquoi les modifications de la base de donn\u00e9es de WordPress ont besoin d’un contr\u00f4le de version<\/h2>\n
Les modifications manuelles de la base de donn\u00e9es traitent les changements de sch\u00e9ma comme des op\u00e9rations ponctuelles plut\u00f4t que comme du code versionn\u00e9. Par exemple, vous ex\u00e9cutez une requ\u00eate SQL<\/a> pour ajouter une table personnalis\u00e9e, vous ex\u00e9cutez une instruction Les environnements de staging commencent souvent \u00e0 diverger des environnements locaux lorsque vous oubliez de documenter les petites modifications (comme l’ajout d’une colonne \u00e0 la base de donn\u00e9es locale), ce qui entra\u00eene \u00e9galement l’\u00e9chec des d\u00e9ploiements en production. Cela signifie \u00e9galement qu’il n’y a pas de piste d’audit.<\/p>\n Les migrations Laravel<\/a> sont un bon moyen d’\u00e9liminer ces \u00e9checs de coordination car elles traitent les modifications de la base de donn\u00e9es comme du code versionn\u00e9 qui vit dans votre d\u00e9p\u00f4t Git. Ce code est d\u00e9ploy\u00e9 avec votre application et s’ex\u00e9cute dans le m\u00eame ordre dans tous les environnements.<\/p>\n Les migrations Laravel sont des fichiers PHP qui d\u00e9finissent les changements de sch\u00e9ma de base de donn\u00e9es par deux m\u00e9thodes : Le syst\u00e8me de migration suit les changements qui ont \u00e9t\u00e9 ex\u00e9cut\u00e9s en utilisant une table Ce suivi emp\u00eache les migrations de s’ex\u00e9cuter plusieurs fois et vous permet de savoir exactement quelles modifications de sch\u00e9ma ont \u00e9t\u00e9 appliqu\u00e9es \u00e0 un environnement donn\u00e9.<\/p>\n Acorn int\u00e8gre le constructeur de sch\u00e9mas de Laravel, qui fournit une syntaxe PHP fluide pour cr\u00e9er et modifier les tables de la base de donn\u00e9es. Au lieu d’\u00e9crire du code SQL brut, vous utilisez des m\u00e9thodes telles que Vous cr\u00e9ez des migrations via WP-CLI<\/a> :<\/p>\n Cela g\u00e9n\u00e8re un nouveau fichier de migration dans le r\u00e9pertoire La m\u00e9thode Vous ex\u00e9cutez les migrations en attente \u00e0 l’aide de la commande Lorsque vous devez annuler le dernier lot de migrations, vous utilisez la commande Apr\u00e8s avoir ex\u00e9cut\u00e9 les migrations, Database Studio de Kinsta<\/a> (ou tout autre outil de base de donn\u00e9es) vous permet de v\u00e9rifier que les tables et les colonnes attendues existent avec la structure correcte. Vous acc\u00e9dez \u00e0 Database Studio via le tableau de bord MyKinsta en naviguant vers n’importe quel site et en cliquant sur l’onglet Base de donn\u00e9es <\/strong>:<\/p>\n La console SQL incluse vous permet de lancer des requ\u00eates de v\u00e9rification pour confirmer que vos migrations ont cr\u00e9\u00e9 la structure attendue.<\/p>\n Apr\u00e8s avoir cr\u00e9\u00e9 la table Le filtrage vous permet d’examiner des enregistrements ou des colonnes sp\u00e9cifiques sans \u00e9crire de requ\u00eates SQL. Ici, vous cliquez sur les en-t\u00eates de colonne pour trier, vous appliquez des filtres pour restreindre les r\u00e9sultats et vous exportez vos donn\u00e9es :<\/p>\n Ces options d’exportation sont utiles avant de tester les proc\u00e9dures de retour en arri\u00e8re.<\/p>\n Kinsta inclut l’acc\u00e8s SSH<\/a> et WP-CLI dans tous les plans. Cela signifie que vous ex\u00e9cutez des commandes de migration directement sur vos environnements de staging et de production sans aucune configuration suppl\u00e9mentaire.<\/p>\n Pour ex\u00e9cuter des migrations sur un environnement Kinsta, connectez-vous d’abord \u00e0 celui-ci en utilisant SSH<\/a>. Les identifiants se trouvent sur l’\u00e9cran d’information <\/strong>de n’importe quel site dans MyKinsta :<\/p>\n Apr\u00e8s vous \u00eatre connect\u00e9 et authentifi\u00e9, naviguez jusqu’\u00e0 la racine du document de votre site. Pour les sites Radicle, il s’agit du r\u00e9pertoire Le processus de migration affiche une sortie indiquant les migrations en cours et l’\u00e9tat d’ach\u00e8vement de chacune d’entre elles. Cette m\u00e9thode fonctionne \u00e9galement dans les environnements de production et de staging<\/a>, car Acorn suit les migrations de mani\u00e8re ind\u00e9pendante dans la base de donn\u00e9es de chaque environnement.<\/p>\n Les environnements de staging de Kinsta<\/a> sont des espaces s\u00fbrs pour tester les migrations avant de les d\u00e9ployer en production, mais vous avez besoin d’un flux de travail fiable pour les tester. Une fois que vous avez v\u00e9rifi\u00e9 les modifications apport\u00e9es \u00e0 la migration dans Database Studio, testez le rollback pour vous assurer que la m\u00e9thode Pour cela, passez \u00e0 votre environnement de staging dans MyKinsta, naviguez vers l’onglet Base de donn\u00e9es<\/strong> et inspectez les tables que vos migrations ont cr\u00e9\u00e9es ou modifi\u00e9es.<\/p>\n Si vous d\u00e9couvrez des probl\u00e8mes au cours des tests, la commande La pouss\u00e9e s\u00e9lective de Kinsta vous permet de d\u00e9ployer uniquement les changements que vous avez test\u00e9s. Vous pouvez donc choisir de ne pousser que vos fichiers vers la production ou de pousser \u00e0 la fois les fichiers et la base de donn\u00e9es :<\/p>\n Pour les flux de migration, vous ne poussez g\u00e9n\u00e9ralement que les fichiers parce que les migrations s’ex\u00e9cutent sur la base de donn\u00e9es de production existante plut\u00f4t que de l’\u00e9craser avec des donn\u00e9es d’\u00e9tape.<\/p>\n Les flux de migration automatis\u00e9s modifient le sch\u00e9ma de la base de donn\u00e9es lors du d\u00e9ploiement du code, ce qui \u00e9limine les \u00e9tapes manuelles et r\u00e9duit les erreurs de d\u00e9ploiement. Vous y parvenez en ajoutant des commandes de migration \u00e0 votre processus de d\u00e9ploiement, qu’il s’agisse de scripts SSH manuels, de l’automatisation des actions GitHub<\/a> ou d’outils tels que Trellis<\/a> de Roots.<\/p>\n Pour les d\u00e9ploiements manuels utilisant SSH, connectez-vous \u00e0 votre environnement de production et naviguez jusqu’\u00e0 la racine du document. Ensuite, ex\u00e9cutez les commandes suivantes dans l’ordre :<\/p>\n Le drapeau Si vous utilisez les actions GitHub pour le d\u00e9ploiement continu, vous automatisez les migrations dans votre fichier de flux de travail. Radicle inclut une configuration Le flux de d\u00e9ploiement se connecte via SSH, navigue vers votre r\u00e9pertoire de site et ex\u00e9cute la commande de migration.<\/p>\n Pour les d\u00e9ploiements utilisant Trellis, les migrations s’int\u00e8grent dans les crochets de d\u00e9ploiement. Vous incluez les \u00e9l\u00e9ments suivants en modifiant Cela permet d’ex\u00e9cuter les migrations apr\u00e8s que Trellis a termin\u00e9 les autres t\u00e2ches de d\u00e9ploiement. Les migrations s’ex\u00e9cutent dans le r\u00e9pertoire de la nouvelle version, et Trellis g\u00e8re le retour en arri\u00e8re si le d\u00e9ploiement \u00e9choue.<\/p>\n Les fichiers de migration se trouvent dans le r\u00e9pertoire Le flux de validation des migrations suit un mod\u00e8le coh\u00e9rent :<\/p>\n Une fois que vous avez examin\u00e9 la migration, vous fusionnez la branche de fonctionnalit\u00e9s avec La commande Cependant, toutes les migrations ne sont pas enti\u00e8rement r\u00e9versibles. Alors que vous pouvez simplement supprimer une table pour annuler sa cr\u00e9ation, une migration qui supprime des donn\u00e9es est une action permanente. Parfois, Il est bon de documenter ces limitations. Les sauvegardes automatis\u00e9es<\/a> de Kinsta constituent un filet de s\u00e9curit\u00e9, il est donc \u00e9galement important de cr\u00e9er une sauvegarde manuelle avant d’ex\u00e9cuter une migration qui pourrait causer des probl\u00e8mes :<\/p>\n Naviguez vers votre site, cliquez sur Sauvegardes<\/strong>, et g\u00e9n\u00e9rez une sauvegarde avec un nom descriptif. Si une migration provoque des probl\u00e8mes inattendus dans la production, vous restaurez \u00e0 partir de cette sauvegarde via MyKinsta.<\/p>\n Pour les retours de migration, vous ne restaurez que la base de donn\u00e9es dans l’environnement de production. La restauration s’effectue en quelques minutes et ram\u00e8ne votre base de donn\u00e9es \u00e0 l’\u00e9tat exact captur\u00e9 dans la sauvegarde.<\/p>\n Les migrations Laravel via l’impl\u00e9mentation d’Acorn<\/a> par Radicle<\/a> transforment ce qui est souvent une source d’anxi\u00e9t\u00e9 en un processus pr\u00e9visible et contr\u00f4l\u00e9 par version. La combinaison des migrations en tant que code, des environnements de staging de Kinsta et de Database Studio pour la v\u00e9rification cr\u00e9e un flux de travail qui vous permet de d\u00e9tecter les probl\u00e8mes de sch\u00e9ma avant qu’ils n’atteignent la production.<\/p>\n En tant que tel, le d\u00e9veloppement moderne de WordPress qui inclut des outils tels que Radicle et Acorn signifie que vous n’avez pas \u00e0 choisir entre l’\u00e9cosyst\u00e8me de WordPress et les cadres d’outils professionnels. Le m\u00eame sch\u00e9ma s’applique aux files d’attente Laravel<\/a>, au templating Blade<\/a> et aux commandes WP-CLI personnalis\u00e9es via Acorn.<\/p>\nALTER TABLE<\/code> pour ajouter des colonnes, ou vous vous fiez aux crochets d’activation des extensions pour g\u00e9rer les mises \u00e0 jour. Ces solutions fonctionnent dans un premier temps, mais elles s’effondrent lorsque vous g\u00e9rez plusieurs environnements ou que vous travaillez avec une \u00e9quipe.<\/p>\nComment les migrations Laravel fonctionnent dans WordPress avec Acorn<\/h2>\n
up()<\/code> applique les changements et down()<\/code> les inverse. Chaque fichier de migration re\u00e7oit un pr\u00e9fixe d’horodatage qui d\u00e9termine l’ordre d’ex\u00e9cution. Roots’ Acorn<\/a> apporte ce syst\u00e8me de migration (et plus encore) \u00e0 WordPress sans n\u00e9cessiter une installation compl\u00e8te de Laravel.<\/p>\nmigrations<\/code> dans votre base de donn\u00e9es WordPress. Lorsque vous ex\u00e9cutez wp acorn migrate<\/code>, Acorn effectue quelques t\u00e2ches :<\/p>\n\n
$table->string('key')->unique()<\/code> ou $table->json('value')->nullable()<\/code>. Cette approche offre une syntaxe agnostique \u00e0 la base de donn\u00e9es, une s\u00e9curit\u00e9 de type et un code plus lisible que les instructions SQL avec des cha\u00eenes concat\u00e9n\u00e9es.<\/p>\nCr\u00e9er et ex\u00e9cuter votre premi\u00e8re migration<\/h3>\n
wp acorn make:migration create_app_settings_table<\/code><\/pre>\ndatabase\/migrations\/<\/code> avec l’horodatage actuel et le nom que vous avez sp\u00e9cifi\u00e9 :<\/p>\n<?php\nuse IlluminateDatabaseMigrationsMigration;\nuse IlluminateDatabaseSchemaBlueprint;\nuse IlluminateSupportFacadesSchema;\n\nreturn new class extends Migration\n{\n public function up(): void\n {\n Schema::create('app_settings', function (Blueprint $table) {\n $table->id();\n $table->string('key')->unique();\n $table->json('value')->nullable();\n $table->string('group')->default('general');\n $table->boolean('is_public')->default(false);\n $table->text('description')->nullable();\n $table->timestamps();\n $table->index('group');\n $table->index('is_public');\n });\n }\n\n public function down(): void\n {\n Schema::dropIfExists('app_settings');\n }\n};<\/code><\/pre>\nup()<\/code> cr\u00e9e la table avec des colonnes pour le stockage des paires cl\u00e9-valeur, le regroupement des r\u00e9glages et le suivi de la date de cr\u00e9ation ou de modification des entr\u00e9es. Les index sur group<\/code> et is_public<\/code> am\u00e9liorent les performances des requ\u00eates. La m\u00e9thode down()<\/code> supprime compl\u00e8tement la table, ce qui vous permet d’inverser la migration.<\/p>\nwp acorn migrate<\/code>. Cette commande ex\u00e9cute toutes les migrations qui n’ont pas encore \u00e9t\u00e9 ex\u00e9cut\u00e9es, cr\u00e9e des tables et modifie le sch\u00e9ma de votre base de donn\u00e9es. Vous pouvez v\u00e9rifier quelles migrations ont \u00e9t\u00e9 ex\u00e9cut\u00e9es \u00e0 l’aide de la commande wp acorn migrate:status<\/code>. La sortie d’\u00e9tat affiche chaque fichier de migration avec des indicateurs indiquant s’il a \u00e9t\u00e9 ex\u00e9cut\u00e9.<\/p>\nwp acorn migrate:rollback<\/code>. Celle-ci ex\u00e9cute la m\u00e9thode down() <\/code>pour chaque migration du dernier lot afin d’annuler les modifications.<\/p>\nV\u00e9rification des migrations avec Database Studio<\/h2>\n
![\"L'interface](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/01\/database-studio.png\")
app_settings<\/code>, la requ\u00eate DESCRIBE app_settings;<\/code> vous permet de v\u00e9rifier les colonnes. Elle renvoie la structure de la table en indiquant les noms, les types et les index des colonnes. Une autre requ\u00eate : SELECT * FROM app_settings;<\/code> vous permet de v\u00e9rifier que la table accepte les insertions.<\/p>\n![\"Une](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/01\/database-filters.png\")
Ex\u00e9cuter des migrations avec SSH et WP-CLI sur Kinsta<\/h2>\n
![\"Trouver](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/01\/ssh-credentials.png\")
public<\/code>. Ensuite, vous ex\u00e9cutez wp acorn migrate<\/code>.<\/p>\nTester les migrations dans les environnements de staging Kinsta<\/h3>\n
![\"L'\u00e9cran](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/01\/create-environment.png\")
down()<\/code> fonctionne correctement.<\/p>\nwp acorn migrate:rollback<\/code> 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\u00e9ployer \u00e0 nouveau la migration et effectuer un nouveau test.<\/p>\n![\"L'interface](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/01\/selective-push.png\")
Flux de d\u00e9ploiement avec des migrations automatis\u00e9es<\/h2>\n
git pull origin main\ncomposer install --no-dev\nnpm install && npm run build\nwp acorn optimize\nwp acorn migrate --force<\/code><\/pre>\n--force<\/code> indique \u00e0 Acorn d’ex\u00e9cuter les migrations sans demande de confirmation, ce qui est essentiel pour les d\u00e9ploiements automatis\u00e9s o\u00f9 vous ne pouvez pas interagir avec le terminal. L’ex\u00e9cution de cette commande apr\u00e8s wp acorn optimize<\/code> permet de s’assurer que le cache de l’application est frais avant l’ex\u00e9cution des migrations.<\/p>\n.github\/workflows\/deploy.yml<\/code> que vous modifiez pour inclure une \u00e9tape de migration apr\u00e8s le processus de construction :<\/p>\n- name: Run migrations\n run: |\n ssh user@host -p port 'cd \/path\/to\/site && wp acorn migrate --force'<\/code><\/pre>\ndeploy-hooks\/finalize-after.yml<\/code> :<\/p>\n- name: Run Acorn migrations\n command: wp acorn migrate --force\n args:\n chdir: \"{{ deploy_helper.new_release_path }}\"<\/code><\/pre>\nContr\u00f4le de la version des fichiers de migration avec Git<\/h3>\n
database\/migrations\/<\/code> de la structure de votre projet Radicle. Ce r\u00e9pertoire fait partie de votre r\u00e9pertoire Git<\/a>, ce qui signifie que les migrations voyagent avec votre code \u00e0 travers le contr\u00f4le de version. Le flux de travail refl\u00e8te le d\u00e9veloppement standard : cr\u00e9er des migrations localement, les livrer \u00e0 une branche de fonctionnalit\u00e9, et les fusionner \u00e0 la branche principale apr\u00e8s les avoir test\u00e9es.<\/p>\ngit add database\/migrations\/2025_01_03_140000_create_app_settings_table.php\ngit commit -m \"Add app_settings table migration\"\ngit push origin feature-branch<\/code><\/pre>\nmain<\/code>, ce qui rend la migration disponible pour les d\u00e9ploiements en phase de staging et en production.<\/p>\nwp acorn migrate:status<\/code> v\u00e9rifie que tous les environnements appliquent les m\u00eames migrations. Vous ex\u00e9cutez cette commande dans tous les environnements pour confirmer qu’ils sont synchronis\u00e9s. Si un environnement affiche des migrations en attente, cela signifie qu’il a besoin d’un d\u00e9ploiement ou d’une migration manuelle pour rattraper son retard.<\/p>\nStrat\u00e9gies de retour en arri\u00e8re et sauvegardes des bases de donn\u00e9es<\/h2>\n
down()<\/code> peut vous indiquer pourquoi un retour en arri\u00e8re n’est pas possible :<\/p>\npublic function down(): void\n{\n \/\/ This migration cannot be reversed as we're deleting data\n Log::warning(\"Migration cannot be reversed - data permanently deleted\");\n}<\/code><\/pre>\n![\"Sauvegardes](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/01\/manual-backups.png\")
Construire des flux de donn\u00e9es fiables pour WordPress<\/h2>\n