Implementación continua de WordPress y control de versiones con Bitbucket

Bien, amigos. Es hora de confesarse.

Si eres como yo, pasaste la primera etapa de tus años de desarrollo de WordPress "codificando como un vaquero", es decir, haciendo cambios salvajes en sitios activos, probándolos urgentemente y encendiéndolos con FTP, lo que a menudo resultó en 500 mensajes de error interno del servidor y todo el sitio rompe todo lo visible para sus estimados visitantes.

Si bien esto fue absolutamente emocionante mientras la adrenalina corría por tus dedos, golpeando ese punto y coma olvidado, en los sitios con más de 0 visitantes (que en realidad notaron el tiempo de inactividad) esto comenzaba a convertirse en un problema. Si un árbol cae y no hay nadie para oírlo, ¿hace ruido? Depende de la teoría de la humanidad a la que te suscribas.

Sin embargo, si un sitio falla y alguien está allí para verlo, seguramente emitirá un sonido.

Implementación continua de WordPress hecha incorrectamente

Ingrese a los sitios de prueba, duplique las instalaciones de WordPress (al menos en teoría) donde se puedan realizar cambios y luego vuelva a realizarlos en el sitio en vivo una vez que se confirme que todo funciona. Si bien esto calmó a los visitantes, comenzó a hacer que los desarrolladores hiciéramos algo de ruido. De repente, necesitábamos realizar un seguimiento de dos sitios, asegurarnos de que el código se sincronice manualmente entre ellos y probar todo nuevamente para asegurarnos de que funciona en el sitio en vivo. Las listas largas y desordenadas de "asegúrese de cambiar esto en vivo" y "asegúrese de alternar esto en el sitio de prueba antes de copiar el código" fueron estresantes, por decir lo menos. Las copias de seguridad de este sistema también fueron una pesadilla: una gran cantidad de carpetas llamadas "my-theme-staging-1" y "my-theme-live-before-menu-restyle-3", etc.

Tenía que haber una mejor manera, y la había.

Estaba Git, que brinda un control de fuente perfecto y otras características a los desarrolladores. El uso del control de versiones para las instalaciones de WordPress aceleró y limpió instantáneamente el desarrollo, ya que ya no se dedicaron horas a realizar copias de seguridad en un sistema por desarrollador, sino a la codificación. Se guardaron los cambios y finalmente pude agregar mensajes significativos a mi trabajo, un mundo de diferencia con "mi-tema-4-v2".

Si bien el código base era mucho más limpio, el problema seguía siendo las implementaciones reales y garantizar que el sitio en cuestión estuviera usando el código más reciente: ingrese la oportunidad de un error humano. Seguir confiando en las cargas FTP manuales que sobrescribían el código anterior no se sentía muy bien. Si bien existían otros servicios de CI/CD, muchos de ellos venían con una etiqueta de precio considerable y una gran cantidad de configuración: reconfiguración del servidor, dependencia de otro servicio incluso para el sitio web más simple, aprendizaje de la "manera de hacer las cosas" completa del otro servicio y todo las idiosincrasias que lo acompañan.

Si bien se pueden realizar configuraciones similares a las de este tutorial con GitHub/GitLab y otros servicios, puse mis huevos en la canasta de Atlassian desde el principio debido a sus repositorios privados gratuitos (que solo ha sido una oferta reciente de GitHub). Cuando Bitbucket presentó sus servicios Pipelines and Deployments , permitió que el nuevo código se implementara automáticamente en los sitios de preparación o producción (o cualquier otro sitio intermedio) sin volver a cargar a través de FTP o mediante un servicio externo. Los desarrolladores ahora podían usar todos los valores del control de fuente en su desarrollo de WordPress y enviar instantáneamente esos cambios a los destinos apropiados sin clics ni pulsaciones de teclas adicionales, con el estado de todo visible a través de un tablero. Esto garantiza que todo permanezca sincronizado y, de un vistazo, le permite saber exactamente qué código está ejecutando cada sitio. Además, el precio de los minutos de compilación de Bitbucket es increíblemente asequible, con 50 minutos gratis al mes y una opción para un plan "Gratis con excedentes".

Tomó un poco de tiempo de inicio descubrir cómo usar mejor las ramas y otras características del control de código fuente en este nuevo modelo y los detalles de la configuración de Bitbucket Pipelines. Este es el proceso que utilizo para iniciar nuevos proyectos de WordPress. No voy a entrar en detalles sobre la configuración de git y la instalación de WordPress, ya que los grandes recursos para eso están a solo una búsqueda de Google. Al final, el flujo de contenido será algo como esto:

La rutina de implementación de Alexa Green WordPress

Los pasos descritos aquí deben realizarse según sea necesario:

En el servidor del cliente

Configure un dominio para el sitio activo (p. ej., sitiocliente.com) y un subdominio para el ensayo (p.ej., ensayo.sitiocliente.com).

Instale WordPress tanto en el sitio en vivo como en el subdominio de ensayo. Esto se puede hacer a través de cPanel/Softaculous (si el hosting del cliente lo tiene) o descargándolo desde wordpress.org. Asegúrese de que haya bases de datos separadas para directo y puesta en escena, respectivamente.

En Bitbucket.com

Configure un nuevo repositorio. Incluya un archivo .README para ponernos en marcha.

En el repositorio, Configuración > Canalizaciones > Configuración y luego marque Habilitar canalizaciones .

En Configuración > Canalizaciones > Variables del repositorio , ingrese lo siguiente:

 Name: FTP_username Value: The client FTP username

 Name: FTP_password Value: The client FTP password 

Vuelva a Pipelines > Configuración y haga clic en el botón Configurar bitbucket-pipelines.yml . Seleccione PHP como idioma en la página siguiente. Querrás usar algo como el siguiente código. Asegúrese de reemplazar la versión de PHP con lo que esté usando en el servidor del cliente, y los servidores URL/FTP con los servidores URL/FTP del sitio real del cliente (producción y puesta en escena).

 image: php:7.1.29 pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com 

Haga clic en Confirmar archivo . La configuración de Pipelines ahora se confirmará y ejecutará.

Si todo se implementa correctamente, regrese y edite el archivo bitbucket-pipelines.yml (puede acceder a través de Pipelines > Configuración y Ver bitbucket-pipelines.yml ). Deberá reemplazar ambos lugares donde dice git ftp init con git ftp push y save/commit. Esto asegurará que solo se carguen los archivos modificados, lo que le ahorrará minutos de compilación. Su archivo bitbucket-pipelines.yml ahora debería leer:

 image: php:7.1.29 pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com 

Agrega una rama llamada main-dev .

En su máquina local

Clone el repositorio en un directorio vacío que le gustaría usar para la instalación local. Echa un vistazo a la rama main-dev .

Configure una instalación de WP local en este directorio. Hay muchas herramientas para esto: Local by Flywheel, MAMP, Docker, etc. Asegúrese de que todo sea igual (versión de WordPress, versión de PHP, Apache/Nginx, etc.) a lo que se está ejecutando en el servidor del cliente.

Agregue un .gitignore que se vea así. Básicamente, queremos que Git ignore todo excepto wp-content (para evitar problemas de instalación entre instalaciones). También es posible que desee agregar sus propias reglas para ignorar los archivos de copia de seguridad de gran tamaño y los archivos de iconos y DS_Store creados por el sistema.

 # Ignore everything * # But not .gitignore !*.gitignore # And not the readme !README.md # But descend into directories !*/ # Recursively allow files under subtree !/wp-content/** # Ignore backup files # YOUR BACKUP FILE RULES HERE # Ignore system-created Icon and DS_Store files Icon? .DS_Store # Ignore recommended WordPress files *.log .htaccess sitemap.xml sitemap.xml.gz wp-config.php wp-content/advanced-cache.php wp-content/backup-db/ wp-content/backups/ wp-content/blogs.dir/ wp-content/cache/ wp-content/upgrade/ wp-content/uploads/ wp-content/wflogs/ wp-content/wp-cache-config.php # If you're using something like underscores or another builder: # Ignore node_modules node_modules/ # Don't ignore package.json and package-lock.json !package.json !package-lock.json

Guarde y .gitignore .

Realice cambios y comprométase en consecuencia.

Cada vez que se comprometa con main-dev, se activará una carga de FTP en el sitio de ensayo. Cada vez que se comprometa a dominar, se activará una carga FTP en el sitio de producción. Tenga en cuenta que esto usará minutos de compilación, por lo que es posible que desee realizar la mayoría de los cambios locales en una rama fuera de main-dev, luego fusionarse con main-dev una vez que haya terminado el día.

La fusión de main-dev en master traerá todos los cambios de etapa en vivo. Puede comprobar el estado de las canalizaciones y las implementaciones en el repositorio de Bitbucket.org.

Sincronización de bases de datos de WordPress entre instalaciones

Tenga en cuenta que lo anterior solo sincronizará archivos (temas, complementos, etc.). La sincronización de la base de datos entre la producción y la puesta en escena se convierte en un asunto diferente, ya que a menudo los clientes realizan cambios en el sitio en vivo que no se reflejan en el sitio de puesta en escena, y viceversa.

Para sincronizar bases de datos entre instalaciones de WordPress, existen varias opciones. Tradicionalmente, puede actualizar las bases de datos importando/exportando a través de phpmyadmin . Sin embargo, esto es complicado, ya que no puede actualizar ciertas cosas que deben actualizarse, como los enlaces permanentes en el contenido de la publicación. Usando este método, una herramienta favorita es el complemento de URL de actualización de Velvet Blues, que luego puede usar para buscar/reemplazar cualquier instancia de la URL del sitio anterior (por ejemplo, https://staging.clientsite.com) a la nueva URL del sitio ( por ejemplo, https://clientsite.com). También puede usar esto con cadenas y rutas relativas. Este método termina dejando mucho espacio para el error humano: si una cadena reemplazada se escribe incorrectamente, puede hacer que todo el sitio se rompa y no pueda usar el complemento/acceder al tablero.

Si bien un complemento como All-in-One WP Migration ofrece una función de búsqueda/reemplazo lista para usar y es increíblemente fácil de usar, también trae archivos, deshaciendo así los valores de todo nuestro flujo de trabajo de Pipelines. Además, dado que reimporta todas las cargas de wp, puede resultar en archivos enormes y tiempos de carga (por lo tanto, no es apto para mover cambios entre instalaciones). Es mejor reservar un complemento como este para copias de seguridad de todo el sitio con fines de archivo/seguridad.

VersionPress parece una solución interesante, pero aún no se ha probado en muchos entornos de producción. Por ahora, complementos como WP Sync DB o WP Migrate DB Pro parecen ser las mejores soluciones para la gestión de bases de datos. Permiten extraer/empujar bases de datos entre instalaciones al tiempo que ofrecen la opción de actualizar automáticamente las direcciones URL y las rutas. Pueden migrar solo ciertas tablas, como wp_posts solo para publicar contenido, sin perder tiempo en volver a importar usuarios y configuraciones de todo el sitio. Siempre me gusta extraer datos en vivo para asegurarme de que no se sobrescriban datos de producción. Aquí hay una configuración de ejemplo si está utilizando WP Sync DB (más tutoriales disponibles en WP Sync DB github):

1. En el sitio en vivo: configure WP Sync DB con la configuración "Permitir extracción de este repositorio" habilitada.
2. En el sitio de ensayo: configure WP Sync DB con la configuración Pull from Live. Llámalo "en vivo a la puesta en escena".
3. En la configuración de su desarrollador local: configure WP Sync DB con la configuración Pull from Live. Llámalo "live-to-dev".

También es posible que desee configurar una regla de "desarrollo a ensayo" y comprobar la configuración del sitio de ensayo para permitir que se sobrescriba la base de datos.

Terminando

Descubrí que estos métodos tienden a funcionar para la mayoría de los casos de uso, tanto en el desarrollo de un nuevo sitio web de WordPress como para el rediseño/reconfiguración de un sitio ya activo.

Permite implementaciones de código que mantienen todas las versiones del sitio actualizadas sin tiempo/esfuerzo de desarrollo adicional y lógica de migración de base de datos segura e intencional para trabajar entre sitios. La actualización de los complementos también se realiza dentro del control de fuente, por lo que las actualizaciones de los complementos se pueden verificar de manera segura en la etapa de preparación antes de comprometerse con el sitio en vivo, lo que minimiza las interrupciones del sitio de producción.

Si bien ciertamente hay margen de mejora para llevar más de un flujo de trabajo de control de fuente a la administración de la base de datos, hasta que una herramienta como VersionPress se use más en entornos de producción, este método de extracciones/empujes selectivos de la base de datos a través de WP Sync DB o WP Migrate DB Pro parece ser el método más seguro para lidiar con esto. ¡Tiene curiosidad por saber qué funciona para su flujo de trabajo de WordPress, o si después de todo esto prefiere agarrar su lazo y codificarlo!