El concepto es innovador: cada nuevo pull request que creas en Github dispara el despliegue de una copia de tu aplicación — en su propio entorno y url — que dura mientras esté abierto y/o en revisión el pull request en cuestión.
En Get on Board el negocio está creciendo y el codebase crece proporcionalmente. Somos un equipo ágil, 100% remoto y autónomo, y queremos tomar ventaja de eso, abrazamos el peligro que acompaña a la velocidad. Hasta hace poco no teníamos ni siquiera ambiente de staging, en serio, era directo, de localhost a producción. De hecho, tenemos varios fuckups en nuestro aval, incluso un día hace varios años nos echamos nuestra base de datos (otro día les cuento 😬).
“Felizmente” ya no estamos tan debajo del radar; somos más conocidos, por ende las cagadas también son más conocidas y pesan más. Necesitamos agregar un poco de pequeñas capas de control sin sacrificar la autonomía. Y bueno, nada mejor para esto que contar con más ojos ayudando a revisar los nuevos cambios.
Por todo esto habilitamos en nuestro pipeline de integración continua la opción de crear review apps. De nuevo, el concepto es sencillo pero mega útil: cada vez que creas un pull request puedes pedirle a Heroku[1] que cree una nueva aplicación — basada en alguno de las otras aplicaciones/ambientes que tengas, dígase staging o producción — y la libere en su propia url. Piénsalo, esto es pull requests on steroids que te permiten beneficios como:
- Aislar los cambios en tu propia versión de la aplicación, tuya y de nadie más.
- Feedback instantáneo de tu código, los cambios están disponibles visualmente en minutos.
- Como la aplicación está disponible en una url, la puedes compartir con más personas: el resto del team, con amigos, tus clientes, tu vieja, tu abuelita.
- Ningún otro pull request compite con el tuyo, no hay que hacer fila para desplegarlo en staging o QA.
- Seguridad para hacer cosas más complejas como refactors grandotes, cambios de schema de la base de datos, nuevas integraciones, cambios de branding, de UX o de UI.
- Autonomía, autonomía, autonomía y pila de cosas más. Por cierto le viene como anillo al dedo a los equipos ágiles. Por ahí ya empiezan a escribir sobre la tendencia https://about.gitlab.com/2019/04/19/progressive-delivery-using-review-apps/ 👌.
Suena maravilloso, entonces ¿cómo se hace todo esto de incorporar y configurar las Review Apps? ¿En qué ambiente me baso? ¿Qué pasa con la base de datos, las variables de entorno, el envío de mails, el sistema de caché, las tareas en background? Además, mi aplicación usa custom domains y https. Y ojo, espero que todo esto no aumente los costos de Heroku mes a mes, ya tengo staging, QA y producción, no quiero pagar un peso más.
Es mucho para agregarlo acá, necesita un post aparte, nada es complejo una vez que entiendes qué hace Heroku cuando crea una review app. En verdad hay bastante documentación — aunque media escondida y a veces no muy clara — para casi todo el setup. En nuestro caso por ejemplo nos costó entender cómo crear custom domains o asignar variables de entorno “on the fly” mientras la review app se liberaba.
En conclusión, review apps como concepto es sencillo pero trae pila de beneficios. No tengo idea cómo funciona en otros proveedores de entornos en la nube, pero si usas Heroku la tienes fácil: un archivo de setup, tus scripts y ya está.
Desde-tu-laptop 💻 → GitHub PR → Review App → Internet 🌎 → a compartir la url con tu abuelita 🎉.
Sigue, parte 2: ¿Cómo diablos se configura todo esto?
[1] Review apps es un concepto desligado de la plataforma. Heroku tiene su propia implementación.
Latest on Blog
