Implementaciones continuas para WordPress usando acciones de GitHub

1. DevOps es para todos
2. Los conceptos básicos de un flujo de trabajo de implementación continua.
3. Cómo implementar con rsync
4. Crear un flujo de trabajo de acciones de GitHub
5. Definir un desencadenador de implementación
6. Construir y verificar el tema.
7. Configurar el acceso y el destino del servidor
8. 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 DESTpara sincronizar archivos de un directorio a otro. Sin embargo, hay un par de opciones que deseas considerar:

• -ccompare los cambios de archivos por suma de comprobación, no por tiempo de modificación
• -hgéneros números en un formato más legible para humanos
• -aconserva los atributos y permisos de los archivos y copia recursivamente archivos y directorios
• -vmuestra la salida de estado
• --deleteeliminar archivos del destino que ya no se encuentran en el origen
• --excludeevita la sincronización de archivos específicos como el .gitdirectorio 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/ ./ [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 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 .yamlplantilla que se envía al .github/workflowsdirectorio de su repositorio.

Cuando se guarda, el flujo de trabajo verifica su código de repositorio y ejecuta algunos echocomandos. nameayuda a seguir el estado y los resultados más adelante. runContiene 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. Recetas faciles y rápidas

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 productionrama:

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 checkoutcomando.

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 rsynccomando se ejecute correctamente, GitHub necesita acceder a SSH en su servidor. Esto se puede lograr haciendo lo siguiente:

1. Generar una nueva clave SSH (sin frase de contraseña)
2. Agregue la clave pública a su ~/.ssh/authorized_keysservidor de producción
3. Agregue la clave privada como secreto con el nombre DEPLOY_KEYal 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 rsynccomando. 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 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:

1. Gatillo en cada empujón a la productionrama.
2. dependencias instaladas
3. Construya y verifique el código
4. 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: '[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 empujando su masterrama a la productionrama:

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

Tal vez te puede interesar:

1. La innovación no puede mantener la Web rápida
2. Rendimiento web ultrarrápido
3. Tabla de contenidos fijos con estados activos de desplazamiento
4. “cambiar tamaño: ninguno;” en áreas de texto es una mala experiencia de usuario

Implementaciones continuas para WordPress usando acciones de GitHub

DevOps es para todosLos conceptos básicos de un flujo de trabajo de implementación continua.Cómo implementar con rsyncCrear un flujo de trabajo de acciones

programar

es

https://aprendeprogramando.es/static/images/programar-implementaciones-continuas-para-wordpress-usando-acciones-de-github-1401-0.jpg

2024-09-28

Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente