Ambientes y despliegues en el desarrollo in-house

Es conveniente repasar la Ilustracion 1 antes de empezar porque hay una correlación entre la rama de desarrollo y el ambiente de despliegue: master con PRODUCCION, release con QA y develop con TEST. Es decir que el código que está en develop ES el que ejecuta en el ambiente de TEST y así. El sistema de integración continua despliega automáticamente en cada ambiente cuando el código de cada una de esas ramas cambia.

TEST

Todos los sistemas deberían contar con un ambiente (o entorno, o segmento) de TEST. El objetivo de este ambiente es el probar la funcionalidad del próximo reléase; es decir, toda aquella funcionalidad que va a formar parte de la próxima versión del software y que está en la rama develop.

El ambiente de TEST es para que los encargados de TESTING (y las herramientas de testing automatizado) de ese componente ejecuten el plan de pruebas diseñado. En este ambiente también pueden ejecutarse pruebas de aceptación de los usuarios antes de cada release, pero si el sistema cuenta también con ambiente de QA, es mejor que los usuarios prueben en ese ambiente porque es más estable.

Grado de estabilidad de un ambiente.

El grado de estabilidad de un ambiente se refiere a la frecuencia con que la funcionalidad se ve modificada. En un ambiente de TEST esta frecuencia es alta porque el sistema de integración continua está todo el tiempo desplegando el software con la nueva funcionalidad que los programadores van reintegrando a la rama principal de desarrollo (develop). En un ambiente de QA esto es menos frecuente y menos aún en uno de PRODUCCION.

QA

El ambiente de QA debe ser un ambiente lo más parecido al ambiente de PRODUCCION para usar como PRE-PRODUCTIVO o PRE-RELEASE. Este ambiente es más estable que el de TEST porque solo se despliega automáticamente cuando se corrige un error y no es un ambiente para agregar funcionalidad. En este ambiente es donde se hacen las pruebas de aceptación y donde se vuelven a ejecutar los TEST pero esta vez con datos reales como los que están en PRODUCCION. Todos los sistemas públicos (que se acceden desde internet) deben tener un ambiente de QA para que los nuevos clientes puedan usar de sandbox antes de integrarse. Si se llega a descubrir un error en este ambiente debe corregirse solo aquí, los cambios deberían pasar automáticamente a develop cuando el release se libera y esta versión entra a PRODUCCION. Obviamente cada cambio de código (corrección) en este ambiente debe desplegarse automáticamente.

Es probable que igualar la infraestructura de QA a la de PRODUCCION sea prohibitivo, eso es algo que los responsables evaluarán con el negocio. También es probable que poner un sistema en QA implique poner varios otros de los que este depende. Esa decisión es responsabilidad de los diseñadores de la solución que pueden optar por usar mocks en lugar de los sistemas reales.

Produccion

No hay una consideración especial para este ambiente, es simplemente el ambiente productivo.

Despliegues.

Los despliegues a los ambientes de QA y PROD deben ser transparentes para los usuarios o clientes de APIs; es decir, no puede haber corte de servicio. Hay varias estrategias para lograr esto por ejemplo blue-green deployments (https://martinfowler.com/bliki/BlueGreenDeployment.html). Además de transparentes deben ser automáticos y responsabilidad del sistema de integración continua. Esto no significa que no los autorice nadie, solamente que no hay una persona que esté copiando archivos a mano previamente compilados en cualquier equipo. Como la rama master (Ilustracion. 1) nunca cambia directamente sino solamente a partir de liberar un release, no hay peligro de despliegues no autorizados a PRODUCCION.

Los despliegues a TEST se realizan de la misma forma que a PROD y a QA pero no hace falta que sea transparente para el usuario. Estos despliegues automáticos se realizan cada vez que la rama develop se modifica; esto es, cada vez que una rama de feature con una funcionalidad nueva se reintegra a la rama develop. De esta forma las herramientas de testing automático se pueden disparar y los integrantes del proyecto pueden saber rápidamente si hay alguna modificación que hace que otra cosa deje de funcionar, por un lado; y por otro, deja disponible rápidamente al equipo de testing y/o a los usuarios la nueva funcionalidad o bugfix.

Blindaje

Los tres ambientes mencionados ya estaban blindados al momento de la escritura de este documento y por lo tanto no hay nada más que agregar. Blindados significa que es imposible el alcance de uno desde el otro, salvo con reglas especiales responsabilidad del equipo de Redes y debidamente documentadas.