Review apps en Heroku: ¿Cómo se configuran? — parte 2

En la primera parte de la serie explicamos qué son, así como los beneficios de implementar review apps como parte del pipeline de desarrollo y despliegue de tu aplicación en Heroku. En este post damos tips de cómo configurar ciertas partes de una review app no tan bien documentadas y mostramos ejemplo de cómo lo hicimos nosotros.

Un archivo de configuración

Las review apps son creadas manual o automáticamente cuando un pull request es creado en GitHub. Heroku usa el archivo app.json en la raíz del proyecto para configurarla(s).

Todo el setup que necesita la aplicación es especificado en este archivo, por mencionar algunos: los add-ons y sus planes (qué base de datos, o servidor de cache necesita y el precio), los buildpacks (soporte que necesita la app para ser ejecutada, por ejemplo la JVM de Java o cierta versión de NodeJS o Ruby), las variables de ambiente, el hardware (cantidad de dynos web y/o worker así como el tamaño de cada uno), el stack (versiones de linux y librerías, esto es importante si se estás probando una migración a un stack diferente), o los scripts (ejecutados luego de creada, o antes de ser destruída la app — más sobre esto luego).

Cómo crear y configurar una review app está bien documentado/actualizado acá y acá, por lo que en el post solo daremos tips — que no encuentras en la doc — y cómo en Get on Board implementamos ciertas particularidades de nuestra aplicación, tales como alimentar la base de datos o cambiar el DNS para soportar dominios personalizados.

Variables de entorno inyectadas

Hay tres variables de entorno que Heroku inyecta a toda review app y que pueden ser útiles en el momento de querer personalizar tu aplicación:

• HEROKU_APP_NAME: El nombre de la review app que Heroku genera en forma random para evitar colisión. Una vez creada el nombre no cambia más
• HEROKU_BRANCH: El nombre del branch remoto en al cual está basado el pull request
• HEROKU_PR_NUMBER : El número del pull request en GitHub

Ambiente de Rails

Heroku usa la misma convención que Rails para saber sobre qué ambiente ejecutar la aplicación mirando dentro de la variable RAILS_ENV.

Cuál valor escoger entre staging o producción es normalmente basado en qué se quiere validar en una review app, pero lo más común es que estén basadas en staging. En nuestro caso el pipeline está formado por development → review apps → staging → production, y las RA están basadas en el ambiente de staging que hace parity con producción, de esa forma tenemos una aproximación a producción donde es posible jugar y equivocarse.

Scripts

Hay dos comandos opcionales que son ejecutados en el ciclo de vida de una review app y que puedes personalizar:

• postdeploy: Se ejecuta una sola vez cuando la RA es creada y después que se ejecuta la fase de release. No es ejecutado en cambios subsecuentes en el pull request como nuevos commits. Es usando este script donde por ejemplo insertas datos de prueba o configuras el DNS, más sobre esto luego
• pr-predestroy: Se ejecuta antes de que se destruye la RA — de forma manual o porque se hace merge del pull request — y sirve para hacer un cleanup de cualquier configuración que hayas hecho en el comandopostdeploy

Tip: Si necesitas ejecutar código cada vez que haya una actualización del pull request y por ende de la review app usa la fase de release, que no es más que una entrada en el archivo Procfile. Por ejemplo release: rails db:migrate va a asegurarse de siempre verificar y ejecutar las migraciones pendientes en la base de datos.

Ejemplos de nuestra configuración

Sigue un fragmento de nuestro app.json con comentarios que puedes usar como guía mientras estudias la documentación en Heroku:

# Nuestra infraestructura consta de 1 dyno web y 1 dyno worker
“formation”: [
  { “process”: “web”, “quantity”: 1 },
  { “process”: “worker”, “quantity”: 1 }
],
# Usamos bases de datos postgresql y redis,
# y un servidor de memcache - (todos gratis en la RA ;)
"addons": [
  "heroku-postgresql:hobby-basic",
  "memcachier:dev",
  "heroku-redis:hobby-dev"
],
# Las variables de ambiente. Es recomendable que las secrets
# como api or access tokens sean inicializadas directamente al
# configurar las review apps, acá la doc en Heroku.
"env": {
  "HEROKU_API_TOKEN": "<access-token-here>",
  "DNSIMPLE_ACCESS_TOKEN": "<access-token-here>",
  "DNSIMPLE_DEV_ACCOUNT_ID": "<account-id>",
  "RAILS_ENV": "staging"
  ...
},
# Ejecuta tareas tipo rake al crear y destruir la review app
"scripts": {
  "postdeploy": "rails getonbrd:heroku:review_app_setup getonbrd:db:create_sample_data",
  "pr-predestroy": "rails getonbrd:heroku:review_app_predestroy"
}

Scripts

Nota como en el script postdeploy ejecutamos una tarea que alimenta la base de datos create_sample_data y antes review_app_setup. En está última configuramos un DNS externo (creando entradas CNAME) y luego creamos varios dominios personalizados para la review app.

Luego en el script pr-predestroy ejecutamos la tareareview_app_predestroy que limpia la misma tabla DNS (borrando las entradas CNAME) antes de que se destruya la aplicación y por ende los dominios personalizados.

Un par de notas respecto a los scripts:

• (a) Para crear los datos de prueba aprovechamos el mecanismo fixtures de rails, conveniente por la forma en que se declaran y organizan los datos usando archivos yaml
• (b) Luego para crear los dominios personalizados usamos una cuenta en DNSimple que brinda una API para jugar con la configuración de los DNS. Además usamos la API de Heroku para crear los dominios en la review app

Síguenos si quieres enterarte de cómo hicimos (a) y (b) que explicaremos en más detalles en próximos posts de la serie.

Como siempre si quiere compartir tus tips o tienes dudas o preguntas relacionadas con este post puedes dejarnos un comentario en el chat o escribirnos directamente a team@getonbrd.com 🤗