Un ambiente refiere a hardware y software donde se ejecuta una aplicación. Dependiendo del proceso de desarrollo la cantidad de ambientes por los cuales iremos propagando una aplicación desde desarrollo hasta producción. Cada ambiente tiene su propia base de datos y su copia de los binarios de la aplicación de forma que no haya interferencias en los ambientes y entre los diferentes participantes en la construcción del software.
Es recomendable que cada desarrollador trabaje en su propio ambiente con su propia base de datos y su propia KB conectada al GxServer.
El “consolidado” o Build-KB corresponde a la KB desde donde se generan los binarios que se van a promover entre los diferentes ambientes. Esta KB es de “solo lectura”, es decir, solo realiza updates del GxServer y nunca commits (esto podría automatizarse si trabajamos con CI). Típicamente la KB del consolidado está “conectada” al ambiente de pruebas de integración.
Los binarios generados en la Build-KB se testean en ambiente(s) dedicados de pruebas. En caso de contar con pruebas automatizadas se recomienda tener un ambiente separado para pruebas manuales y otro para las automatizadas, ya que las pruebas automatizadas necesitan correr sobre un set de datos controlados.
Dependiendo del proceso de desarrollo, entre el ambiente de pruebas hasta llegar al ambiente de producción puede haber uno o varios ambientes intermedios –i.e. QA, UAT, Pre-Prod, etc. -. Se recomienda que sean todos lo más parecidos al ambiente de producción posible.
Es importante tener en cuenta que lo que se promueve entre ambientes son los binarios que han sido testeados y aprobados, es decir, la última instancia de compilación es el Build-KB y desde allí avanzan solo binarios.
Ciclo de desarrollo / pruebas / instalación / producción
Una funcionalidad es desarrollada inicialmente por un desarrollador, testeada de forma local por el desarrollador y cuando es aprobada se sube al GxServer y se integra en la Build-Kb (ya sea manual o automáticamente por el CI).
Una vez que se generan los binarios en el consolidado, se ejecutan las pruebas automáticas (si las hay) y las pruebas manuales en el ambiente de prueba. Si las mismas son aprobadas, los binarios avanzan al siguiente ambiente y así hasta llegar al paquete para ser instalado en producción.
Ventajas:
- Los binarios que llegan a producción son exactamente los mismos aprobados en los ambientes de tests.
Desventajas
- No tenemos una copia exacta del código que se encuentra en Pre-Prod (porque podría pasar que para codificar la Funcionalidad 2 se hayan modificado objetos incluidos en la Funcionalidad 1).
Si tenemos la Build-KB en una máquina virtual entonces en vez de copiar los binarios desde el ambiente de prueba al ambiente de pre-producción, es posible realizar una copia de la máquina virtual donde está la Build-KB. No avanzan solo los binarios sino la KB entera en cada promoción. De esta forma se mantiene la ventaja del modelo anterior y se combate su desventaja (en el diagrama podemos ver que las KBs se identifican por el ultimo commit q existía en el momento en que se generó la máquina virtual).
Hay varias estrategias para realizar esto, lo importante siempre es contar con una KB que tenga el código que fue a producción y se puedan generar desde allí las correcciones necesarias.
La ida a producción se realiza desde un Branch – que se realiza cuando la versión está suficientemente estable -. De esta forma lo que avanza hacia producción es un branch (i.e. 1.0). Cuando se comienza a desarrollar nueva funcionalidad se realiza en el Trunk, de esta forma siempre contamos con la KB de Build que tiene el código tal cual fue a producción (y desde donde se generaron los binarios de producción)
Con la misma idea de aprovechar la virtualización, se genera una copia de la máquina virtual donde se encuentra la Build-KB en el momento que se va a producción de forma de poder continuar realizando soporte desde allí.
La mayoría captura las reorganizaciones (SQL) y genera los scripts que luego son usados para reorganizar los diferentes ambientes. Los motivos son variados:
- Separación de responsabilidades (i.e. el equipo de desarrollo no tiene acceso a los ambientes de producción)
- Problemas de GeneXus para ejecutar ciertas reorganizaciones (que hacen que sea mas seguro utilizar los scripts que guardar los binarios de las reorganizaciones tal como las genera GeneXus).
Para ver la mesa redonda del tema: https://www.youtube.com/watch?v=iGIAe3AjDus