Flujo de Integración Continua en GitHub Actions

Clase 12 de 18 • Curso de GitHub Actions

Resumen

A lo largo de este recorrido, descubriremos los componentes, conceptos y sintaxis esenciales que hacen de GitHub Actions una herramienta clave para cualquier flujo de trabajo de desarrollo de software.

¿Cómo Aplicar lo Aprendido a un Proyecto Personal?

Para internalizar y aplicar todo lo aprendido, te recomiendo que elijas un proyecto personal en el que hayas estado trabajando. Esto debe ser un proyecto original, o bien, puede ser un proyecto open source que encuentres interesante y disponga en GitHub de forma pública.

¿Cuál es un Ejemplo de Cómo Implementar un Flujo de Integración y Despliegue Continuo?

Un ejemplo específico que vamos a trabajar es el proyecto UIS Shop, mantenido por OWASP, una organización internacional que se centra en la seguridad de Internet. Este proyecto es un e-commerce, realizado con Angular para el frontend y Node para el backend, que vende zumos y algunos productos relacionados.

Este proyecto también cuenta con su propia serie de tests unitarios, integración, fin a fin y otros automatizables. Además, la aplicación se puede compilar en un formato (Docker), cumpliendo con los requisitos del flujo de integración continua. El resultado de esta compilación puede llevarse a cualquier tipo de servidor para su despliegue continuo.

Posteriormente, mostraremos cómo crear flows específicos para cada tipo de test y trabajaremos en distintos jobs dentro de estos flujos. Además, aprenderemos la herramienta "Retry", cómo copiar y subir reportes de coverage, y cómo verificar nuestra aplicación en distintos contextos y navegadores.

GitHub Actions ofrece la flexibilidad y el nivel de personalización que necesitas para maquetar eficientemente tus proyectos. ¡Vamos a descubrirlo juntos!

Julio César Cid

student•

los parámetros de los actions se pasan con el parámetro "with:"

Jesus Daniel Castro Flores

student•

me causa duda porque en los run viene o bien el pipe "|" o este signo de mayor que ">". No me queda claro en este tipo de contexto porque usarlo asi.

Juan José Torres

Team Platzi•

Estos nos permiten usar comandos de bash en varias líneas sin romper la sintaxis de los workflow files.

Nos permiten tener algo como:

run: |
	echo"COUNTRY=${{ env.PAIS }}" >> $GITHUB_ENV
	echo"INFORMATION=${{ env.INFORMACION }}" >> $GITHUB_ENV

En vez de:

- name: Definir pais
    run: echo "COUNTRY=${{ env.PAIS }}" >> $GITHUB_ENV
  - name: Definir información
    run: echo "INFORMATION=${{ env.INFORMACION }}" >> $GITHUB_ENV

Diego Reyes Cabrera

student•

Profe, y en el caso del ">"? Porque veo que igual se utiliza el && en cada comando

Luis Enrique Rendon Cortez

student•

Es importante conocer el alcance de cada tipo de test, dejo un poco de información de ellos.

Test unitario -> Evaluación a nivel de componente para asegurar que cada unidad de código funcione correctamente de manera aislada.

Test de integración -> Verificación de la interacción y correcta combinación de unidades de código para asegurar el funcionamiento adecuado del sistema completo.

Test de Humo -> Prueba inicial para identificar fallos básicos y verificar que las funciones principales del sistema estén operativas.

José Ángel Hernández Radilla

student•

needs indica que un job solo se puede ejecutar cuando los jobs especificados hayan concluido correctamente

needs: [test,test-api]

Víctor Rolack

student•

🚀 Estoy alucinando con lo que se puede hacer con GitHub Actions 😍

Estoy trabajando en el backend de una app personal que estamos desarrollando con mi esposa, y aproveché el curso para automatizar varios flujos clave del proyecto.

✅ Le agregué un workflow de testing que se ejecuta en cada Pull Request y en los merges a main y develop. Este workflow valida que todos los tests pasen y que el coverage no baje del 90%. Si no se cumple, ¡el merge no pasa! 💥

🔥 Luego integré semantic-release, y creé un workflow que se encarga automáticamente del changelog, del versionado y de las pre-releases o releases finales. Ya no tengo que preocuparme por actualizar la versión o el changelog manualmente: ¡todo se hace al hacer merge a develop o main! 🤖📦

🛠️ En la última etapa, cuando esté cerca del primer release oficial, voy a crear un workflow de despliegue continuo, tanto para staging como para producción. Todo va a quedar listo para tener entornos separados y automatizados.

✨ De verdad, tremendo curso. Siento que desbloqueé superpoderes como dev 😎

Gracias Platzi por estas joyas 🙌

Javier Perez

student•

Sobre el uso de pipe (|) y signo mayor qué (>), ambos se usan para representar comandos/textos multilinea. La diferencia es que el '|' toma literal el texto presentado a continuación, salto de líneas incluido.

run: |
          npm install --ignore-scripts
          cd frontend
```Sería&#x20;

```js
npm install --ignore-scripts <ENTER>
cd frontend

Mientras que el '>', toma todas las siguientes líneas y las concatena, siendo interpretadas como una línea única, sin caracter de salto de línea

name: "Lint customization configs"
        run: >
          npm run lint:config -- -f ./config/7ms.yml &&
          npm run lint:config -- -f ./config/addo.yml &&
```Pasa a ser:

`npm run lint:config -- -f ./config/7ms.yml && npm run lint:config -- -f ./config/addo.yml`

Fredy Daniel Flores Lemus

student•

En esencia, al usar una etiqueta de versión (como v3) en nuestros actions, existe el riesgo, aunque pequeño, de que dicha etiqueta sea reasignada a un commit diferente debido a malas prácticas. Esto puede llevar a cambios inesperados en el código al que apunta la etiqueta. Por otro lado, al referenciar directamente un commit, garantizamos la inmutabilidad del código, ya que los commits son fijos y no pueden cambiar.

David Enrique Lizarazo Vesga

student•

Tengo una duda respecto a los actions/checkout; Para un job que se encuentre selfHosted, el actions/checkout descarga el repositorio dentro de la carpeta del runner dentro del servidor, cierto?

Si yo dentro del servidor cuento ya con una carpeta donde tengo los repositorios,y especifico el directorio de trabajo (working-directory) puedo omitir esta parte de checkout repositorio y configuración de Node en mis actions de despliegue ? Hay alguna buena practica que lo impida?

De antemano muchas gracias.