Configurar un flujo de integración continua que ejecute pruebas y envíe automáticamente tu proyecto a producción es una de las prácticas más valiosas en el desarrollo moderno. Aquí se recorre paso a paso cómo unir cambios en master, activar Travis CI y verificar que el deploy se complete solo cuando las pruebas pasan correctamente.
¿Cómo enviar los cambios al repositorio y fusionarlos con master?
El primer paso consiste en llevar la configuración de Travis al repositorio remoto. Desde la terminal se ejecuta la secuencia habitual de Git [0:10]:
git status para revisar los archivos modificados.git add . para añadir todos los cambios pendientes.git commit -m "Travis config" para crear el commit con un mensaje descriptivo.git push origin 08jesci para enviar la rama al repositorio en GitHub.
Una vez que la rama está disponible en GitHub, se crea un pull request [0:42] para fusionarla con master. Al ser administrador del proyecto, la unión se aprueba directamente. Con esto, el repositorio principal ya contiene el archivo .travis.yml junto con todo el código del proyecto acumulado a lo largo de las etapas anteriores.
¿Qué sucede cuando Travis CI detecta cambios en master?
Dentro del panel de Travis se habilita el repositorio y se genera un trigger de construcción [1:20]. Este trigger indica a Travis que debe iniciar el proceso completo: asignar una máquina virtual, clonar el repositorio, leer la configuración del archivo .travis.yml e instalar el environment especificado —en este caso la versión 12 de Node.
El flujo que Travis ejecuta de forma automática es el siguiente [1:50]:
- Lee el repositorio y asigna el token de autenticación.
- Instala todas las dependencias del proyecto.
- Corre las pruebas con Jest (Yes en el audio).
- Si las pruebas pasan, ejecuta el comando de build.
- Finalmente realiza el deploy a GitHub Pages mediante la rama
gh-pages.
Cuando todo aparece en verde, significa que las pruebas pasaron y la construcción fue exitosa [2:38]. Al visitar la sección Settings del repositorio en GitHub, se puede ver que la rama gh-pages ya está habilitada y el proyecto queda disponible en producción.
¿Cómo verificar que el deploy fue exitoso?
Dentro de Settings > GitHub Pages el sistema detecta automáticamente la rama gh-pages y habilita la URL pública [2:55]. Al acceder a esa dirección se confirma que la aplicación —en este ejemplo Platzi Store— está funcionando correctamente en producción gracias al deploy automático de Travis.
¿Qué ocurre cuando una prueba falla?
Para demostrar el comportamiento ante un error, se modifica intencionalmente un test. En el archivo de prueba del componente Footer se cambia la cadena esperada: en lugar de buscar "Platzi Store" se busca solo "Platzi" [3:20].
Los cambios se envían directamente a master:
git add .git commit -m "footer test"git push origin master
Como la configuración de Travis está escuchando la rama master, se dispara automáticamente un nuevo build [3:45]. Travis repite todos los pasos —clonar, instalar dependencias, configurar el entorno— y aprovecha el caché que se estableció previamente para acelerar la construcción.
¿Por qué Travis impide el deploy cuando las pruebas no pasan?
Al llegar a la etapa de pruebas, el output muestra en rojo que el valor esperado no coincide [4:15]. Jest reporta que la aserción falló porque "Platzi" no es igual a "Platzi Store". Aunque el build técnicamente se puede completar, Travis no envía el proyecto a producción porque las pruebas no pasaron.
Este mecanismo es fundamental: garantiza que solo el código que supera las validaciones llegue al entorno productivo. Si una prueba se rompe, el equipo debe corregirla y enviar un nuevo commit para que Travis vuelva a intentar el ciclo completo.
La responsabilidad del desarrollador es escribir pruebas idóneas que realmente verifiquen el comportamiento crítico de la aplicación. Una prueba mal diseñada puede bloquear un deploy válido o, peor aún, dejar pasar código defectuoso. ¿Has experimentado algún caso en el que Travis te salvó de enviar un error a producción? Comparte tu experiencia.
