Implementaciones continuas para WordPress usando acciones de GitHub
- DevOps es para todos
- Los conceptos básicos de un flujo de trabajo de implementación continua.
- Cómo implementar con rsync
- Crear un flujo de trabajo de acciones de GitHub
- Definir un desencadenador de implementación
- Construir y verificar el tema.
- Configurar el acceso y el destino del servidor
- Juntar las piezas
Los flujos de trabajo de integración continua (CI) se consideran una de las mejores prácticas en estos días. Es decir, usted trabaja con su sistema de control de versiones (Git) y, mientras lo hace, CI hace el trabajo por usted, como ejecutar pruebas, enviar notificaciones e implementar código. Esa última parte se llama Despliegue Continuo (CD). Pero enviar el código a un servidor de producción a menudo requiere servicios de pagos. Con GitHub Actions, la implementación continua es gratuita para todos. Exploramos cómo configurarlo.
DevOps es para todos
Como desarrollador front-end, los flujos de trabajo de implementación continua solían ser interesantes, pero misteriosos para mí. Recuerdo que muchas veces tuve miedo de tocar los ajustes de implementación. En su lugar, opté por la ruta fácil: generalmente pedirle a otra persona que lo configure y lo mantenga, o copiar y pegar cosas manualmente en el peor de los casos.
Tan pronto como entendí los conceptos básicos de rsync, CD finalmente se volvió tangible para mí. Con el siguiente flujo de trabajo de GitHub Action, no es necesario ser un especialista en DevOps; pero aún tendrá las herramientas a mano para configurar flujos de trabajo de implementación de mejores prácticas.
Los conceptos básicos de un flujo de trabajo de implementación continua.
Entonces, ¿cuál es el problema? ¿Cómo funciona esto? Todo comienza con CI, lo que significa que usted envía el código a un repositorio remoto compartido, como GitHub, y cada vez que se inserta en él se ejecutarán tareas automatizadas en un servidor remoto. Esas tareas podrían incluir procesos de prueba y construcción, como linting, concatenación, minificación y optimización de imágenes, entre otras.
El CD también entrega código a un servidor de sitio web de producción. Esto puede suceder copiando el código verificado y creado y colocándolo en el servidor a través de FTP, SSH o enviando contenedores a una infraestructura. Si bien todos los paquetes de alojamiento compartido tienen acceso FTP, enviar muchos archivos a un servidor es bastante poco confiable y lento. Y si bien enviar contenedores de aplicaciones es una forma segura de lanzar aplicaciones complejas, la infraestructura y la configuración también pueden ser bastante complejas. Sin embargo, implementar código a través de SSH es rápido, seguro y flexible. Además, es compatible con muchos paquetes de alojamiento.
Cómo implementar con rsync
Una forma fácil y eficiente de enviar archivos a un servidor a través de SSH es rsync, una herramienta de utilidad para sincronizar archivos entre una carpeta, unidad o computadora de origen y de destino. Sólo sincronizará aquellos archivos que hayan cambiado o que aún no existan en el destino. Como se convirtió en una herramienta estándar en distribuciones populares de Linux, es muy probable que ni siquiera necesite instalarla.
La operación más básica es tan fácil como llamar rsync SRC DEST
para sincronizar archivos de un directorio a otro. Sin embargo, hay un par de opciones que deseas considerar:
-c
compare los cambios de archivos por suma de comprobación, no por tiempo de modificación-h
géneros números en un formato más legible para humanos-a
conserva los atributos y permisos de los archivos y copia recursivamente archivos y directorios-v
muestra la salida de estado--delete
eliminar archivos del destino que ya no se encuentran en el origen--exclude
evita la sincronización de archivos específicos como el.git
directorio ynode_modules
Y finalmente, desea enviar los archivos a un servidor remoto, lo que hace que el comando completo se vea así:
rsync -chav --delete --exclude /.git/ --exclude /node_modules/ ./ ssh-user@example.com:/mydir
Puede ejecutar ese comando desde su computadora local para implementarlo en cualquier servidor en vivo. Pero, ¿qué tan genial sería si se ejecutara en un entorno controlado desde un estado limpio? Bien, para eso estás aquí. Sigamos con eso.
Crear un flujo de trabajo de acciones de GitHub
Con GitHub Actions configurar puedes flujos de trabajo para que se ejecuten en cualquier evento de GitHub. Si bien existe un mercado para GitHub Actions, no necesitamos ninguna de ellas, pero crearemos nuestro propio flujo de trabajo.
Para comenzar, vaya a la pestaña “Acciones” de su repositorio y haga clic en “Configurar un flujo de trabajo usted mismo”. Esto abrirá el editor de flujo de trabajo con una .yaml
plantilla que se envía al .github/workflows
directorio de su repositorio.
Cuando se guarda, el flujo de trabajo verifica su código de repositorio y ejecuta algunos echo
comandos. name
ayuda a seguir el estado y los resultados más adelante. run
Contiene los comandos de shell que desea ejecutar en cada paso.
Definir un desencadenador de implementación
En teoría, cada confirmación a la rama maestra debería estar lista para producción. Sin embargo, la realidad le enseña que también debe probar los resultados en el servidor de producción después de la implementación y programarlo. En bleech consideramos que es una buena práctica implementar solo los días laborables (excepto los viernes y solo antes de las 4:00 pm) para asegurarnos de que tenemos tiempo para retroceder o solucionar problemas durante el horario laboral si algo sale mal.
Una forma sencilla de obtener control a nivel manual es configurar una rama solo para activar implementaciones. De esa manera, puedes fusionar específicamente tu rama maestra cuando estés listo. Llame a esa rama de producción, informe a todos los miembros de su equipo que los envíos a esa rama solo están permitidos desde la rama principal y dígales que lo hagan de esta manera:
git push origin master:production
A continuación se explica cómo cambiar el activador de su flujo de trabajo para que solo se ejecute en envíos a esa production
rama:
name: Deploymenton: push: branches: [ production ]
Construir y verificar el tema.
Asumiré que estás usando nuestro tema inicial de WordPress Flynt, que viene con administración de dependencias a través de Composer y npm, así como un proceso de compilación preconfigurado. Si está utilizando un tema diferente, es probable que el proceso de compilación sea similar, pero es posible que necesite ajustes. Y si está registrando los activos creados en su repositorio, puede omitir todos los pasos excepto el checkout
comando.
Para nuestro ejemplo, asegurémonos de que el nodo se ejecute en la versión requerida y que las dependencias estén instaladas antes de compilar:
jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: actions/setup-node@v2 with: node-version: 12.x - name: Install dependencies run: | composer install -o npm install - name: Build run: npm run build
La tarea de compilación de Flynt finalmente requiere lints, compilar y transpilar archivos Sass y JavaScript, luego agregar revisión a los activos para evitar problemas de caché del navegador. Si algo en el paso de compilación falla, el flujo de trabajo dejará de ejecutarse y, por lo tanto, evitará que implemente una versión defectuosa.
Configurar el acceso y el destino del servidor
Para que el rsync
comando se ejecute correctamente, GitHub necesita acceder a SSH en su servidor. Esto se puede lograr haciendo lo siguiente:
- Generar una nueva clave SSH (sin frase de contraseña)
- Agregue la clave pública a su
~/.ssh/authorized_keys
servidor de producción - Agregue la clave privada como secreto con el nombre
DEPLOY_KEY
al repositorio
El paso del flujo de trabajo de sincronización necesita guardar la clave en un archivo local, ajustar los permisos del archivo y pasar el archivo al rsync
comando. El destino debe apuntar a su directorio de temas de WordPress en el servidor de producción. Es conveniente definirlo como una variable para saber qué cambiar al reutilizar el flujo de trabajo para proyectos futuros.
- name: Sync env: dest: 'ssh-user@example.com:/mydir/wp-content/themes/mytheme' run: | echo "${{secrets.DEPLOY_KEY}}" deploy_key chmod 600 ./deploy_key rsync -chav --delete -e 'ssh -i ./deploy_key -o StrictHostKeyChecking=no' --exclude /deploy_key --exclude /.git/ --exclude /.github/ --exclude /node_modules/ ./ ${{env.dest}}
Dependiendo de la estructura de su proyecto, es posible que también desee implementar complementos y otros archivos relacionados con el tema. Para lograrlo, cambie el origen y el destino al directorio principal deseado, asegúrese de verificar si los archivos excluidos necesitan una actualización y verifique si se debe ajustar alguna ruta en el proceso de compilación.
Juntar las piezas
Hemos cubierto todos los pasos necesarios del proceso de CD. Ahora necesitamos ejecutarlos en una secuencia que debería:
- Gatillo en cada empujón a la
production
rama. - dependencias instaladas
- Construya y verifique el código
- Enviar el resultado a un servidor mediante rsync
El flujo de trabajo completo de GitHub se verá así:
name: Deploymenton: push: branches: [ production ]jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: actions/setup-node@v2 with: node-version: 12.x - name: Install dependencies run: | composer install -o npm install - name: Build run: npm run build - name: Sync env: dest: 'ssh-user@example.com:/mydir/wp-content/themes/mytheme' run: | echo "${{secrets.DEPLOY_KEY}}" deploy_key chmod 600 ./deploy_key rsync -chav --delete -e 'ssh -i ./deploy_key -o StrictHostKeyChecking=no' --exclude /deploy_key --exclude /.git/ --exclude /.github/ --exclude /node_modules/ ./ ${{env.dest}}
Para probar el flujo de trabajo, confirme los cambios, introdúzcalos en su repositorio local y active la implementación empujando su master
rama a la production
rama:
git push origin master:production
Puede seguir el estado de la ejecución yendo a la pestaña “Acciones” en GitHub, luego seleccionando la ejecución reciente y haciendo clic en el trabajo “implementar”. Las marcas de verificación verdes indican que todo salió bien. Si hay algún problema, consulte los registros del paso fallido para solucionarlo.
Consulta el informe completo en GitHub
¡Felicidades! Ha implementado con éxito su tema de WordPress en un servidor. El archivo de flujo de trabajo se puede reutilizar fácilmente para proyectos futuros, lo que facilita las configuraciones de implementación continua.
Para perfeccionar aún más su proceso de implementación, vale la pena considerar los siguientes temas:
- Dependencias de almacenamiento en caché para acelerar el flujo de trabajo de GitHub
- Activar el modo de mantenimiento de WordPress mientras sincroniza archivos
- Borrar la caché del sitio web de un complemento (como Cache Enabler) después de la implementación
Deja un comentario