Cuando tu pipeline de integración continua ya ejecuta builds y deploys automáticos con cada push, el siguiente paso natural es enterarte al instante de lo que sucede. Configurar notificaciones por correo electrónico en Travis CI garantiza que todo el equipo —DevOps, front-end leader, back-end leader— reciba alertas tanto de éxitos como de fallos, sin necesidad de revisar el dashboard manualmente.
¿Cómo verificar que tu build se ejecutó correctamente?
Una vez que Travis CI termina de procesar un cambio, el dashboard muestra información valiosa [01:06]:
- Estado en verde si todo pasó sin errores.
- Tiempo de ejecución del build.
- Rama sobre la que se ejecutó y el usuario que realizó el cambio.
- Configuración convertida a JSON que Travis utiliza internamente.
Dentro del panel también encuentras el Build History, donde puedes consultar el historial completo de ejecuciones. Si trabajas con pull requests, Travis los detecta y ejecuta las pruebas sobre ellos de forma independiente [04:24]. Además, puedes marcar un proyecto como favorito para acceder más rápido desde el dashboard principal.
¿Cómo configurar notificaciones por email en Travis CI?
La configuración se agrega directamente en el archivo .travis.yml, antes de la sección de deploy [02:12]. La estructura necesaria es la siguiente:
yaml
notifications:
email:
recipients:
- usuario@platzi.com
- correopersonal@ejemplo.com
on_success: always
on_failure: always
Cada propiedad cumple un rol específico:
- notifications: bloque principal que activa el sistema de alertas.
- email: indica que el canal de notificación será correo electrónico.
- recipients: lista de direcciones que recibirán los correos, separadas por guiones. Aquí defines a las personas clave del equipo.
- on_success: controla el comportamiento cuando el build pasa correctamente. El valor
always asegura que siempre se envíe.
- on_failure: controla el comportamiento cuando el build falla. Con
always, recibirás aviso en cada error.
Es importante revisar la indentación del archivo YAML, ya que un typo o una sangría incorrecta provocará que la configuración no se interprete bien [03:18].
¿Cómo enviar los cambios para activar las notificaciones?
Después de guardar el archivo, el flujo en terminal es directo [03:30]:
bash
git status
git add .
git commit -m "update Travis"
git push origin master
Travis detecta automáticamente el nuevo push y dispara un nuevo build. Cada cambio que llega a master ejecuta las pruebas y el proceso de compilación completo.
¿Qué ocurre con los pull requests y ramas adicionales?
Para comprobar que el flujo también cubre pull requests, puedes crear una rama nueva —por ejemplo, develop— directamente desde el editor web de GitHub [04:42]. Al hacer un cambio mínimo, como editar el archivo README, y generar un pull request hacia master, Travis ejecuta un build independiente sobre esa rama.
En el historial se puede observar cómo los builds se ejecutan tanto sobre master como sobre develop [05:38]. Si el build en la rama pasa correctamente, los cambios se empujan a GitHub Pages de forma automática.
¿Qué información contienen los correos de notificación?
Al abrir la bandeja de entrada, encontrarás correos enviados desde builds Travis con esta información [06:02]:
- Estado del build: indica si pasó o falló.
- Nombre del commit: por ejemplo, "update Travis" o "update README".
- Rama afectada: master, develop u otra.
- Autor del cambio: identifica quién realizó el push.
- Destinatarios copiados: todos los recipients configurados aparecen en el correo.
Esta visibilidad permite que el equipo completo tenga control del flujo sin depender de una sola persona. Cada miembro sabe cuándo hay una nueva versión disponible o cuándo algo se rompió, y puede actuar en consecuencia.
Si quieres llevar las notificaciones a otro nivel, el siguiente paso es integrarlas con herramientas de mensajería como Slack para que el equipo reciba alertas en tiempo real dentro de sus canales de trabajo. ¿Ya configuraste notificaciones en tus proyectos? Comparte tu experiencia en los comentarios.
