Guía Completa de Git
para QA con CI/CD en
GitHub Actions
Un flujo de trabajo eficiente para gestionar pruebas,
integraciones y automatización en entornos de QA.
Introducción
Propósito:
Explicar cómo establecer un flujo de trabajo efectivo
utilizando Git y CI/CD en GitHub Actions para
garantizar la estabilidad del código y la integración
continua en el entorno de QA.
Importancia del flujo de trabajo:
El uso de Git en entornos de aseguramiento de la
calidad (QA) es fundamental para gestionar los
cambios en el código y garantizar su estabilidad.
Integrar Git con CI/CD en GitHub Actions permite
automatizar pruebas, mejorar la calidad del código y
acelerar los despliegues. En este artículo,
exploraremos un flujo de trabajo eficiente para QA en
Git utilizando GitHub Actions.
¿Qué es GitHub Actions?
GitHub Actions es un servicio de automatización que
permite definir flujos de trabajo dentro de un
repositorio. Mediante archivos de configuración en
formato YAML, se pueden automatizar procesos como
la ejecución de pruebas, la compilación de código y el
despliegue de aplicaciones.
1. Configurar el Repositorio y las Ramas
Antes de comenzar, asegúrese de tener un repositorio
en GitHub con los permisos adecuados y una
estructura bien organizada.
Estructura de ramas recomendada: Para un flujo de
trabajo estructurado, se recomienda la estrategia de
ramas GitFlow o una variación simplificada:
main: Contiene el código estable y aprobado.
develop: Rama de desarrollo donde se integran
nuevas funcionalidades.
feature/: Ramas temporales para nuevas
características.
bugfix/: Ramas para corregir errores.
hotfix/: Correcciones urgentes en la rama main.
test/: Ramas para ejecutar pruebas antes de
fusionar cambios.
2. Crear una nueva rama para QA
Paso a paso: Cómo crear una rama para realizar
pruebas?
Para llevar a cabo pruebas sin afectar el código principal, es
recomendable crear una rama específica. A continuación, se
detalla el proceso:
1. Actualizar el repositorio local:
2. Crear una nueva rama de pruebas: Se recomienda usar un
nombre descriptivo, por ejemplo: test/casos-usuario.
3. Realizar cambios y agregar archivos:
4. Subir la rama al repositorio remoto:
Una vez creados y verificados los cambios, la rama de
pruebas puede ser utilizada en GitHub Actions para
ejecutar los test automatizados.
3. Ejecutar pruebas y validar código
Pruebas manuales o automáticas
Para asegurar la calidad del código, se pueden realizar
pruebas manuales o automatizadas. Algunas herramientas
útiles incluyen:
Cypress: Ideal para pruebas de frontend en aplicaciones
web.
Selenium: Permite automatizar pruebas en diferentes
navegadores.
Ejemplo de ejecución de pruebas con Cypress:
Ejemplo de ejecución de pruebas con Selenium (Python):
Reportar errores
Si se detectan errores durante las pruebas, es fundamental
documentarlos correctamente y comunicarlos al equipo de
desarrollo. Se recomienda:
1. Crear un issue en GitHub con:
Descripción del error.
Pasos para reproducirlo.
Evidencias (capturas de pantalla, logs).
2. Utilizar herramientas de gestión como Jira o Trello para
el seguimiento de los errores.
4. Subir cambios a GitHub
Modificar el código
Cuando se necesita corregir un error o realizar ajustes:
1. Modificar los archivos necesarios.
2. Confirmar los cambios:
3. Actualizar la rama remota:
Con estos pasos, se garantiza un flujo de trabajo eficiente
para QA dentro de Git y GitHub Actions.
5. Crear un Pull Request y Activar CI/CD
Crear un Pull Request (PR)
Una vez completadas las pruebas y modificaciones
necesarias, se debe crear un Pull Request (PR) en GitHub
para fusionar los cambios en la rama principal.
1. Ir al repositorio en GitHub.
2. Seleccionar la rama test/nombre-de-prueba.
3. Hacer clic en Compare & pull request.
4. Agregar una descripción detallada de los cambios.
5. Asignar revisores y etiquetas si es necesario.
6. Hacer clic en Create pull request.
Activación de GitHub Actions
Una vez creado el PR, GitHub Actions ejecutará las
pruebas automáticamente si hay un flujo de trabajo
configurado en .github/workflows/.
Si todas las pruebas pasan, el PR estará listo para
revisión.
Si CI/CD falla:
Revisar los logs en la pestaña Actions de GitHub.
Corregir los errores en la rama y volver a subir
cambios:
5. Crear un Pull Request y Activar CI/CD
Ejemplo de un Workflow en GitHub Actions
Explicación de la estructura del Workflow
name: Define el nombre del flujo de trabajo.
on: Especifica los eventos que activan el workflow (en
este caso, cuando se crea un PR en main o develop).
jobs: Define los trabajos a ejecutar. En este caso, solo
hay un trabajo llamado test.
runs-on: Especifica el sistema operativo en el que se
ejecutará el flujo de trabajo (ubuntu-latest).
steps: Lista los pasos del trabajo:
checkout: Descarga el código del repositorio.
Instalar dependencias: Usa npm install para instalar
los paquetes necesarios.
Ejecutar pruebas: Lanza las pruebas con npm test.
Esto permite que cada vez que se cree un PR, GitHub Actions
automatice la ejecución de pruebas y valide la calidad del
código.
6. Revisar, Aprobar y Fusionar
Una vez que CI/CD pase y el código haya sido revisado, se
procede a la fusión.
Proceso de revisión de un Pull Request (PR):
Asignar revisores: QA Testers y desarrolladores deben
validar la implementación.
Verificar código: Comprobar estándares, calidad y
pruebas exitosas.
Ajustes y comentarios: Si es necesario, solicitar
cambios antes de aprobar.
Flujo de fusión según el Tipo de Cambio
Para Bug Crítico:
Si el cambio es una corrección urgente de un bug, el
proceso debe ser rápido para evitar que el error afecte
a más usuarios.
Se realiza un PR desde una rama específica para la
corrección del bug.
Código de Git:
Una vez revisado y aprobado, el PR se fusiona
rápidamente para que la solución se implemente lo
antes posible.
6. Revisar, Aprobar y Fusionar
Para Nueva Funcionalidad:
Si el cambio es para agregar una nueva funcionalidad, el
proceso de revisión puede ser más extenso. El código se
debe probar exhaustivamente para asegurar que no
rompa nada existente y que cumpla con los requisitos.
Código de Git:
Después de la revisión, y si las pruebas automáticas
pasan correctamente, el PR se fusiona con la rama
principal.
Post-Fusión y Limpieza:
Una vez que el PR se fusiona, se deben realizar algunas
tareas de limpieza, como eliminar la rama que ya no es
necesaria y asegurarse de que no queden conflictos
pendientes.
Código de Git:
7. Desplegar en producción
Despliegue automático
Cuando los cambios sean aprobados en develop, se crean
releases en main. GitHub Actions ejecutará pruebas finales
antes del despliegue automático:
8. Eliminar ramas innecesarias
Mantener Ordenado el Repositorio
Una vez que se han fusionado los cambios de una rama de
características, corrección de errores o cualquier otra tarea
temporal, es importante eliminar las ramas innecesarias
para mantener el repositorio limpio y organizado. Esto
facilita la gestión del código y reduce la posibilidad de
confusión o errores en el futuro.
Aquí te explico cómo hacerlo paso a paso.
1. Eliminar una rama localmente:
Después de haber fusionado los cambios de una rama, es
buena práctica eliminar esa rama en tu repositorio local.
Para ello, puedes usar el siguiente comando:
2. Eliminar una rama remotamente:
Una vez que la rama ha sido eliminada localmente, es
recomendable también eliminarla del repositorio remoto
(GitHub). Esto evitará que otros colaboradores vean o
intenten trabajar en esa rama, manteniendo el repositorio
más limpio.
3. Verificar que la rama se haya eliminado:
Para asegurarte de que la rama ha sido eliminada
correctamente, puedes usar estos comandos:
Resumen del flujo de trabajo en Git
para QA
Recapitulación:
Crear ramas basadas en develop o qa/testing:
Comienza creando una nueva rama para trabajar en una
nueva funcionalidad o corrección de errores, partiendo
de develop o una rama de pruebas (qa/testing).
Realizar pruebas manuales o automáticas: Trabaja en
tu tarea, realizando pruebas manuales o automáticas
(dependiendo del tipo de cambio) para asegurarte de
que todo funcione correctamente.
Subir cambios a GitHub y crear un Pull Request: Una
vez que hayas realizado los cambios, súbelos a GitHub y
abre un Pull Request (PR) para que otros miembros del
equipo lo revisen.
GitHub Actions ejecuta las pruebas automáticamente:
Cuando el Pull Request se crea, GitHub Actions
ejecutará las pruebas automáticas para verificar que los
cambios no rompan el código existente.
Revisar y fusionar cambios en develop o main: Después
de que las pruebas se completen y se apruebe el PR,
revisa el código y fusiona los cambios en la rama
principal correspondiente (develop o main).
CI/CD se encarga del despliegue en producción: Una
vez que los cambios estén fusionados, el proceso de
CI/CD se encargará de ejecutar las pruebas finales y
desplegar los cambios en producción automáticamente.
Limpiar ramas innecesarias: Después de fusionar los
cambios, elimina las ramas que ya no son necesarias
para mantener el repositorio limpio y organizado.
Conclusión
Beneficios de un flujo de trabajo organizado:
Un flujo de trabajo organizado optimiza el proceso de QA al
garantizar que las pruebas se realicen de manera continua y
automática, reduciendo los errores humanos. La
integración de herramientas como GitHub Actions facilita la
colaboración entre equipos al permitir la revisión y prueba
de código de forma eficiente, asegurando que los cambios
no afecten negativamente al software. Esto mejora la
calidad general del producto y reduce significativamente el
riesgo de errores en producción.
Implementa este flujo de trabajo en tus proyectos para
mejorar la calidad del software, optimizar las pruebas y
fomentar una colaboración más ágil y efectiva entre todos
los miembros del equipo.
¡Haz que tu proceso de desarrollo sea más eficiente y
seguro hoy mismo!
