Hector Fernandez CloudparaTodo for AWS Community Builders

Posted on Mar 15 • Updated on Mar 27

[How to] Implementar Ephemeral environments para Pull Request en GitHub

#cloudnative #productivity #developmentcycle #development

Hoy te quiero contar cómo puedes crear tus propios ambientes efímeros usando las herramientas de IaC (Infrastructure as Code) que ya tienes. En mi caso estaré utilizando AWS CDK para el despliegue en la nube, pero el tutorial sirve para cualquier IaC.

Tener la posibilidad de usar Ephemeral environments (ambientes efímeros) al momento de crear una Pull Request es sin dudas una de las mejores herramientas para aumentar la productividad en el desarrollo de software nativo usando la nube. Ya que te permite tener un ambiente listo para hacer tus pruebas de integración (E2E) justo al momento de terminar de codear los cambios.

¿Qué es un Ephemeral environments o Preview environment?

Recordemos que los ambientes “ephemeral” tienen un ciclo de vida corto, fueron creados para una finalidad en particular (en nuestro caso validar el código al momento de la creación de una Pull Request), deben ser lo más parecido al ambiente de producción y estar disponibles cuando el programador los necesite. Muy importante luego de ser utilizados deben ser destruidos con herramientas automatizadas.

Te dejo un post de mi blog con todos los detalles para que puedas profundizar más...https://blog.hectorfernandez.dev/ephemeral-environments-como-crearlos

¿Qué debes de tener?

Repositorio de código (GIT)
Cuenta de AWS
IaC para el despliegue de tus recursos
AWS CLI configurado en tu maquina

Los siguientes pasos están dentro de la capa gratuita de AWS, pero según tu caso de uso puedes incurrir en costos.

1) Identificar nuestra infraestructura (en el código)

El primer paso que debemos de debemos hacer es identificar nuestra infraestructura, por ejemplo ¿usamos contenedores?, usamos servicios de almacenamiento persistentes (S3)? ¿Cómo estos servicios están referenciados en nuestro código?.

¿Pero saber en qué parte del código se hace referencia a servicios externos en qué me ayuda?

por ahora te diría muchísimo.

Al conocer cómo interactúa nuestra aplicación nos permite identificar cuáles parámetros pueden ser pasados por ejemplo mediante variables de entorno. Cuando creamos ambientes de “preview” cómo también se le suele llamar, debemos saber que los nombres de cada entidad son autogenerados, por lo tanto no podremos decidir el nombre o dejar ese nombre de forma estática en el código.

Te muestro un ejemplo, para entender mejor el punto anterior.

 const msg =
    process.env.BUCKET_NAME === "prod"
      ? "Production Mode "
      : "Preview Enviroment";

  return {
    statusCode: 200,
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      message: `Hello from Lambda ${msg} using CDK`,
    }),
  };

Este código es parte de la función serverless de lambda, dónde dependiendo de la variable de entorno pasada se comporta de una u otra manera (esto puede ser tan complejo cómo tu solución lo necesite) es meramente para ilustrar la importancia de identificar la parte que el código hace uso de la infraestructura creada.

2) High-level architecture

En este template podremos ver la idea general de la implementación y cómo quedaría nuestra cuenta luego de tener más de 1 ambiente temporal desplegado.

Como podemos observar nuestra arquitectura es bastante simple para enseñarles la integración que puede tener. La idea es que un ambiente productivo real siga la misma idea pero escalado a la cantidad de recursos que ya tienes.

3) Stack de AWS CDK

4) Github Actions que se encargará de hacer todo esto posible

5) Puntos importantes

Sintetizar nuestra plantilla de cloudformation: 40% más rapido la creación de stacks cloudfromation (Si usas otra herramienta de IaC, sigue los pasos que te indica esa otra herramienta)
Hacer el deploy del stack: Un punto aca super importante es que le pasamos como parámetro el ID del pull request que estamos creando, de esta forma se crea un ID único.
Validar los cambios que hicimos

Ya con esto tendríamos nuestro ambiente desplegado en una cuenta compartida entre todos los desarrolladores pero a su vez cada quien con su stack propio, permitiendo que las pruebas se puedan hacer de forma aislada.

6)Revisando nuestros recursos en AWS

Si vamos a cloudformation desde la consola tendremos algo similar a esto. Tendremos nuestras URL listas para utilizar ¡Lo logramos!
ya con esto vamos a poder hacer nuestras pruebas e2e o cualquier prueba de humo sin mayor esfuerzo.

Tips para mejorar esta solución:

Tener una colección de Postman que pueda correr mediante CI / CD cada vez que se cree una Pull Request, de tal manera de asegurar la integridad de la aplicación.
Implementar comentarios automáticos en Github, de esta forma la URL del ambiente creado queda disponible para todos los reviewers.
Solo hacer despliegue de los componente que sean necesarios según el código que se tocó
Definir un tiempo de vida para el stack, ya que si alguien deja esa PR por mucho tiempo pueda tener un ciclo de vida.

¿Habias utilizado algo similar antes? Me gustaría saber tu opinión de estipo de ambientes en un ciclo de desarrollo continuo.

Connect with me

LinkedIn : https://www.linkedin.com/in/hectorfernandezdev/
GitHub : https://github.com/hectorfernandezdev
Podcast: https://podcast.hectorfernandez.dev/

Let's keep building

Top comments (3)

Guille Ojeda • Mar 28

Me encanta el artículo! Súper importante el tema.
En lo personal los mayores problemas que encontré fueron que a medida que crece la test suite (en especial si empezamos a agregar cosas como load testing) los tiempos de espera se vuelven demasiado largos para un pipeline.
La solución que encontramos es dividir esto en 3:

Pipeline con todos los tests funcionales, que se puede ejecutar a demanda en un branch
Pipeline con test suite de sanity, sobre cada PR
Pipeline nocturno con la test suite completa, incluyendo los test de carga

Claro que todo depende del proceso de desarrollo que uno tenga. En los casos en los que usé ambientes efímeros fue para reemplazar tests manuales que ya se estaban haciendo, así que no poder sumar esto a los unit tests no fue realmente una limitación, de todos modos logramos mejorar mucho el proceso.

Por cierto, me encanta cómo escribiste el artículo!

Hazel Saenz • Mar 27

Excelente tema, yo implemente el uso de ambientes efimeros justo como lo propones pero a nivel mas granular y el único incoveniente que tuve fue el incremento de minutos en los runners de github, dependiendo del tamaño de tu equipo esto puede ser un tema porque puede impactarte en el costo de la licencia de Github y por ende en el costo de tu proyecto. En mi caso lo resolví utilizando self runners y liberando los minutos de Github solo para ambientes productivos. Se los dejo por acá por si se topan con el mismo incoveniente.

Hector Fernandez CloudparaTodo • Mar 27

@hsaenzg buen punto que traes, sin duda que cualquier "replica" nos lleva a aumentar los costos y en tu ejemplo los minutos de los runners de githubs.

Creo que se puede equiparar con el tiempo que pasan los Devs y QA a la espera de una liberación o tambien poder optimizar el uso de ambientes compartidos que ya tengan como "QA ENV" teniendolos solo encendidos en horario laboral por poner un ejemplo.

Para estos casos de build o cuando no te interesa mantener contexto **(Ephemeral environments) **esta bueno darle un ojo a las Spot instances por ejemplo.

_Muchas gracias por sumarte con tu aporte. _

DEV Community