Gestionar los cambios en el esquema de la base de datos en los entornos de WordPress suele ser un proceso propenso a errores y que requiere mucho tiempo. Una sola consulta SQL mal colocada o una modificación olvidada de la base de datos puede provocar un fallo en el sitio web durante el despliegue. Además, acciones como los scripts SQL manuales y las ediciones directas carecen de control de versiones, trazabilidad y coordinación entre entornos.
Una solución es utilizar Radicle de Roots (concretamente Acorn), ya que incorpora las migraciones de Laravel a WordPress. Obtienes cambios en la base de datos controlados por versiones que se despliegan junto a tu código, un seguimiento automático de los cambios que se han ejecutado y la posibilidad de revertir las modificaciones del esquema cuando sea necesario.
Cuando combinas esto con la infraestructura y las herramientas de Kinsta, obtienes una forma de automatizar la ejecución de la migración durante los despliegues.
Por qué los cambios en la base de datos de WordPress necesitan un control de versiones
Las modificaciones manuales de la base de datos tratan los cambios de esquema como operaciones puntuales en lugar de código versionado. Por ejemplo, ejecutas una consulta SQL para añadir una tabla personalizada, ejecutas una instrucción ALTER TABLE para añadir columnas o dependes de hooks de activación de plugins para gestionar las actualizaciones. Estas soluciones funcionan inicialmente, pero fallan cuando gestionas varios entornos o trabajas con un equipo.
Los entornos staging normalmente empiezan a diferir de los locales cuando se olvida documentar cambios menores (como añadir una columna a la base de datos local), lo que también provoca fallos en los despliegues de producción. Esto también implica que no hay un registro de auditoría.
Las migraciones de Laravel son una buena forma de eliminar estos fallos de coordinación, ya que tratan los cambios en la base de datos como código versionado que reside en tu repositorio Git. Esto se realiza durante el despliegue con tu aplicación y se ejecuta en el mismo orden en todos los entornos.
Cómo funcionan las migraciones Laravel en WordPress con Acorn
Las migraciones de Laravel son archivos PHP que definen los cambios en el esquema de la base de datos mediante dos métodos: up() aplica los cambios y down() los revierte. Cada archivo de migración recibe un prefijo de marca de tiempo que determina el orden de ejecución. Roots’ Acorn lleva este sistema de migración (y mucho más) a WordPress sin necesidad de instalar toda la plataforma Laravel.
El sistema de migración rastrea qué cambios se han ejecutado utilizando una tabla migrations en tu base de datos de WordPress. Cuando ejecutas wp acorn migrate, Acorn lleva a cabo unas cuantas tareas:
- Comprueba la tabla para identificar las migraciones pendientes.
- Ejecuta las tablas en orden cronológico basándose en las marcas de tiempo.
- Registra cada migración realizada con éxito.
Este seguimiento evita que las migraciones se ejecuten varias veces y te muestra exactamente qué cambios de esquema se han aplicado a cada entorno.
Acorn integra el generador de esquemas de Laravel, que proporciona una sintaxis PHP fluida para crear y modificar tablas de bases de datos. En lugar de escribir SQL sin procesar, utilizas métodos como $table->string(“key”)->unique() o $table->json(“value”)->nullable(). Este enfoque ofrece una sintaxis independiente de la base de datos, seguridad de tipos y un código más legible que las sentencias SQL con cadenas concatenadas.
Crear y ejecutar tu primera migración
Puedes crear migraciones a través de WP-CLI:
wp acorn make:migration create_app_settings_tableEsto genera un nuevo archivo de migración en el directorio database/migrations/ con la marca de tiempo actual y el nombre que especifiques:
<?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');
}
};El método up() crea la tabla con columnas para almacenar pares clave-valor, agrupar configuraciones y realizar un seguimiento de cuándo se crearon o modificaron las entradas. Los índices en group e is_public mejoran el rendimiento de las consultas. El método down() elimina la tabla por completo, lo que te permite revertir la migración.
Ejecutas las migraciones pendientes con el comando wp acorn migrate. Esto ejecuta todas las migraciones que aún no se han ejecutado, crea tablas y modifica el esquema de tu base de datos. Comprueba qué migraciones se han ejecutado con el comando wp acorn migrate:status. La salida de estado muestra cada archivo de migración con indicadores para saber si se ha ejecutado.
Cuando necesites anular el último lote de migraciones, utiliza el comando wp acorn migrate:rollback. Esto ejecuta el método down() para cada migración del último lote para deshacer los cambios.
Verificar las migraciones con Database Studio
Tras ejecutar las migraciones, Database Studio de Kinsta (o cualquier otra herramienta de base de datos) te permite verificar que existen las tablas y columnas esperadas con la estructura correcta. Accedes a Database Studio a través del panel de control de MyKinsta, navegando a cualquier sitio y haciendo clic en la pestaña Base de Datos:
La Consola SQL incluida te permite ejecutar consultas de verificación para confirmar que tus migraciones han creado la estructura esperada.
Tras crear la tabla app_settings, la consulta DESCRIBE app_settings; te permite verificar las columnas. Esto devuelve la estructura de la tabla mostrando los nombres, tipos e índices de las columnas. Otra consulta: SELECT * FROM app_settings;, te permite comprobar que la tabla acepta inserciones.
El filtrado te permite examinar registros o columnas específicos sin necesidad de escribir consultas SQL. Aquí, puedes hacer clic en los encabezados de columna para ordenar, aplicar filtros para limitar los resultados y exportar tus datos:
Estas opciones de exportación son útiles antes de probar los procedimientos de reversión.
Ejecutar migraciones con SSH y WP-CLI en Kinsta
Kinsta incluye acceso SSH y WP-CLI en todos los planes. Esto significa que puedes ejecutar comandos de migración directamente en tus entornos staging y producción sin necesidad de realizar ninguna configuración adicional.
Para ejecutar migraciones en un entorno Kinsta, primero conéctate a él mediante SSH. Las credenciales se encuentran en la pantalla Información de cualquier sitio dentro de MyKinsta:
Después de conectarte y autenticarte, navega a la raíz del documento de tu sitio. Para los sitios Radicle, este es el directorio public. A continuación, ejecuta wp acorn migrate.
El proceso de migración muestra un resultado que indica qué migraciones se están ejecutando y el estado de finalización de cada una de ellas. Esto también funciona en entornos staging y producción, ya que Acorn realiza un seguimiento independiente de las migraciones en la base de datos de cada entorno.
Probar migraciones en entornos staging de Kinsta
Los entornos staging de Kinsta son un espacio seguro para probar las migraciones antes del despliegue en producción, pero necesitas un flujo de trabajo fiable para poder probarlas. Una vez que hayas verificado los cambios de la migración en Database Studio, comprueba la reversión para asegurarte de que el método down() funciona correctamente.
Para ello, cambia a tu entorno staging en MyKinsta, ve a la pestaña Base de Datos e inspecciona las tablas que han sido creadas o modificadas por tus migraciones.
Si descubres problemas durante las pruebas de staging, el comando wp acorn migrate:rollback te permite revertir el último lote de migraciones y realizar correcciones sin afectar a la producción. A continuación, puedes modificar tus archivos de migración, hacer commit de los cambios, volver a realizar el despliegue en staging y volver a realizar las pruebas.
La función de envío selectivo de Kinsta te permite realizar el despliegue solo de los cambios que hayas probado, por lo que puedes elegir entre enviar solo tus archivos a producción o enviar tanto los archivos como la base de datos:
En los flujos de trabajo de migración, normalmente solo se envían archivos, ya que las migraciones se ejecutan en la base de datos de producción existente en lugar de sobrescribirla con datos de staging.
Flujo de trabajo de despliegue con migraciones automatizadas
Los flujos de migración automatizados ejecutan los cambios en el esquema de la base de datos junto con el despliegue del código, eliminando pasos manuales y reduciendo errores en producción. Esto se consigue añadiendo los comandos de migración al proceso de despliegue, ya sea mediante scripts manuales por SSH, automatización con GitHub Actions o herramientas como Trellis de Roots.
Para despliegues manuales mediante SSH, conéctate a tu entorno de producción y navega hasta la raíz del documento. A continuación, ejecuta estos comandos en secuencia:
git pull origin main
composer install --no-dev
npm install && npm run build
wp acorn optimize
wp acorn migrate --forceLa bandera --force indica a Acorn que ejecute las migraciones sin solicitar confirmación, lo cual es esencial para despliegues automatizados en los que no puedes interactuar con el terminal. Ejecutar este comando después de wp acorn optimize garantiza que la caché de la aplicación esté actualizada antes de que se ejecuten las migraciones.
Si utilizas GitHub Actions para el despliegue continuo, puedes automatizar las migraciones en tu archivo de flujo de trabajo. Radicle incluye una configuración .github/workflows/deploy.yml que puedes modificar para incluir un paso de migración después del proceso de construcción:
- name: Run migrations
run: |
ssh user@host -p port 'cd /path/to/site && wp acorn migrate --force'El flujo de trabajo de despliegue se conecta a través de SSH, navega hasta el directorio de tu sitio y ejecuta el comando de migración.
Para los despliegues que utilizan Trellis, las migraciones se integran en los hooks de despliegue. Incluye lo siguiente modificando deploy-hooks/finalize-after.yml:
- name: Run Acorn migrations
command: wp acorn migrate --force
args:
chdir: "{{ deploy_helper.new_release_path }}"Esto ejecuta las migraciones después de que Trellis complete otras tareas de despliegue. Las migraciones se ejecutan en el nuevo directorio de lanzamiento, y Trellis se encarga de la reversión si el despliegue falla.
Controlar la versión de los archivos de migración con Git
Los archivos de migración se encuentran en el directorio database/migrations/ dentro de la estructura de tu proyecto Radicle. Este directorio forma parte de tu repositorio Git, lo que significa que las migraciones se transfieren junto con tu código a través del control de versiones. El flujo de trabajo refleja el desarrollo estándar: crea migraciones localmente, hacer commit en una rama de funcionalidades y fusionar con la rama principal después de realizar pruebas.
El flujo de commits para las migraciones sigue un patrón consistente:
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-branchUna vez que revises la migración, fusiona la rama de funcionalidad con main. Esto hace que la migración esté disponible para despliegues de staging y producción.
El comando wp acorn migrate:status verifica que todos los entornos tengan aplicadas las mismas migraciones. Ejecuta esto en todos los entornos para confirmar que estén sincronizados. Si un entorno muestra migraciones pendientes, esto indica que necesita un despliegue o una ejecución de migración manual para ponerse al día.
Estrategias de reversión y copias de seguridad de la base de datos
Sin embargo, no todas las migraciones son totalmente reversibles. Aunque puedes simplemente eliminar una tabla para deshacer su creación, una migración que borra datos es una acción permanente. A veces, down() puede decirte por qué no es posible una reversión:
public function down(): void
{
// This migration cannot be reversed as we're deleting data
Log::warning("Migration cannot be reversed - data permanently deleted");
}Es bueno documentar estas limitaciones. Las copias de seguridad automatizadas de Kinsta proporcionan una red de seguridad, por lo que también es importante crear una copia de seguridad manual antes de ejecutar una migración que pueda causar problemas:
Navega a tu sitio, haz clic en Copias de seguridad y genera una copia de seguridad con un nombre descriptivo. Si una migración causa problemas inesperados en producción, restaura desde esta copia de seguridad a través de MyKinsta.
Para las reversiones de migraciones, sólo restauras la base de datos en el entorno de producción. La restauración se completa en cuestión de minutos y devuelve tu base de datos al estado exacto capturado en la copia de seguridad.
Creación de flujos de trabajo de bases de datos fiables para WordPress
Las migraciones de Laravel mediante la implementación de Acorn en Radicle convierten lo que a menudo es una fuente de ansiedad en un proceso predecible y versionado. La combinación de migraciones como código, los entornos staging de Kinsta y Database Studio para la verificación crea un flujo de trabajo en el que los problemas de esquema se detectan antes de llegar a producción.
Por lo tanto, el desarrollo moderno de WordPress, que incluye herramientas como Radicle y Acorn, significa que no tienes que elegir entre el ecosistema de WordPress y los frameworks de herramientas profesionales. El mismo patrón se aplica a las colas de Laravel, las plantillas Blade y los comandos WP-CLI personalizados a través de Acorn.
Si estás listo para adoptar este flujo de trabajo, el siguiente paso es establecer convenciones de migración, como definir patrones de nomenclatura para los archivos de migración, documentar los procesos y establecer requisitos de prueba antes de las fusiones clave. El alojamiento administrado de Kinsta para WordPress ofrece herramientas de desarrollo integradas para ayudar (como acceso SSH, entornos staging y Database Studio) que soportan flujos de trabajo modernos, incluidas las migraciones Radicle y Acorn.
