Implementaciones continuas para WordPress usando acciones de GitHub | Programar Plus

0

Los flujos de trabajo de integración continua (CI) se consideran una mejor práctica en estos días. Al igual que en, usted trabaja con su sistema de control de versiones (Git) y, mientras lo hace, CI hace un 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 pago. Con las acciones de GitHub, la implementación continua es gratuita para todos. Exploremos cómo configurar eso.

DevOps es para todos

Como desarrollador front-end, los flujos de trabajo de implementación continua solían ser emocionantes, pero misteriosos para mí. Recuerdo que muchas veces tuve miedo de tocar las configuraciones de implementación. En su lugar, opté por la ruta fácil: por lo general, alguien más lo configuraba y lo mantenía, o copiaba y pegaba manualmente las cosas en el peor de los casos.

Tan pronto como entendí los conceptos básicos de rsync, el CD finalmente se volvió tangible para mí. Con el siguiente flujo de trabajo de Acción de GitHub, no es necesario ser un especialista en DevOps; pero aún tendrá las herramientas a mano para configurar los 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 lo empuja ejecutará 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 otros.

El CD también envía código a un servidor de sitios web de producción. Eso puede suceder copiando el código verificado y construido 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 aunque el envío de contenedores de aplicaciones es una forma segura de lanzar aplicaciones complejas, la infraestructura y la configuración también pueden ser bastante complejas. La implementación de código a través de SSH es rápida, segura 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, una unidad o una computadora de origen y destino. Solo sincronizará aquellos archivos que hayan cambiado o que aún no existan en el destino. Como se convirtió en una herramienta estándar en las 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 desea considerar:

  • -c compara los cambios de archivo por suma de comprobación, no por tiempo de modificación
  • -h genera números en un formato más legible por humanos
  • -a retiene los atributos y permisos de los archivos y copia de forma recursiva archivos y directorios
  • -v muestra la salida de estado
  • --delete elimina archivos del destino que no se encuentran en la fuente (ya)
  • --exclude evita la sincronización de archivos especificados como el .git directorio y node_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/ ./ [email protected]:/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 las acciones de GitHub, puede configurar los flujos de trabajo para que se ejecuten en cualquier evento de GitHub. Si bien existe un mercado para las acciones de GitHub, 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 un .yaml plantilla que estará comprometida con la .github/workflows directorio de su repositorio.

Cuando se guarda, el flujo de trabajo comprueba su código de repositorio y ejecuta algunos echo comandos. name ayuda a seguir el estado y los resultados más tarde. run contiene los comandos de shell que desea ejecutar en cada paso.

Definir un desencadenante de implementación

Teóricamente, cada compromiso con la rama maestra debería estar listo 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 debe programarlo. En bleech consideramos que es una buena práctica implementar solo los días hábiles, excepto los viernes y solo antes de las 4:00 p. M., Para asegurarnos de que tenemos tiempo para retroceder o solucionar problemas durante el horario comercial si algo sale mal.

Una forma sencilla de obtener el control a nivel manual es configurar una sucursal solo para desencadenar implementaciones. De esa manera, puede fusionar específicamente su rama maestra en ella cuando esté listo. Llame a esa rama de producción, informe a todos los miembros de su equipo que los empujes a esa rama solo están permitidos desde la rama maestra y dígales que lo hagan así:

git push origin master:production

A continuación, le mostramos cómo cambiar el desencadenador de su flujo de trabajo para que solo se ejecute en los empujes a ese production rama:

name: Deployment
on:
  push:
    branches: [ production ]

Construye y verifica el tema

Asumiré que está utilizando nuestro tema de inicio 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 compilados en su repositorio, puede omitir todos los pasos excepto el checkout mando.

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/[email protected]
    
    - uses: actions/[email protected]
      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, compila y transpila archivos Sass y JavaScript, luego agrega 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, le impedirá implementar una versión rota.

Configurar el acceso y el destino del servidor

Para el rsync para ejecutarse correctamente, GitHub necesita acceso a SSH en su servidor. Esto se puede lograr haciendo lo siguiente:

  1. Genere una nueva clave SSH (sin una frase de contraseña)
  2. Agregue la clave pública a su ~/.ssh/authorized_keys en el servidor de producción
  3. Agrega la clave privada como un secreto con el nombre DEPLOY_KEY al repositorio

El paso del flujo de trabajo de sincronización debe guardar la clave en un archivo local, ajustar los permisos del archivo y pasar el archivo al rsync mando. 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: '[email protected]:/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 desee implementar complementos y otros archivos relacionados con el tema también. Para lograr eso, cambie la fuente y el destino al directorio principal deseado, asegúrese de verificar si los archivos excluidos necesitan una actualización y verifique si alguna ruta en el proceso de compilación debe ajustarse.

Juntar las piezas

Hemos cubierto todos los pasos necesarios del proceso de CD. Ahora necesitamos ejecutarlos en una secuencia que debería:

  1. Dispare cada vez que presione el production rama
  2. Instalar dependencias
  3. Construye y verifica el código
  4. Envíe el resultado a un servidor a través de rsync

El flujo de trabajo completo de GitHub se verá así:

name: Deployment

on:
  push:
    branches: [ production ]

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/[email protected]

    - uses: actions/[email protected]
      with:
        node-version: 12.x

    - name: Install dependencies
      run: |
        composer install -o
        npm install

    - name: Build
      run: npm run build
    
    - name: Sync
      env:
        dest: '[email protected]:/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 presionando 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.

Ver 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 hace que las configuraciones de implementación continua sean muy sencillas.

Para refinar aún más su proceso de implementación, vale la pena considerar los siguientes temas:

  • Almacenamiento en caché de dependencias para acelerar el flujo de trabajo de GitHub
  • Activar el modo de mantenimiento de WordPress mientras se sincronizan archivos
  • Borrar la caché del sitio web de un complemento (como Cache Enabler) después de la implementación