¿que es un ambiente de desarrollo?

AMBIENTES DE DESARROLLO

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.




AMBIENTES

Es recomendable que cada desarrollador trabaje en su propio ambiente con su propia base de datos y su propia KB conectada al GxServer.

KB-Build
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. Típicamente la KB del consolidado está “conectada” al ambiente de pruebas de integración.

Ambiente(s) de Prueba
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.

Ambientes de QA/UAT/Pre-Prod/Staging/Producción
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.

Ciclo de desarrollo / pruebas / instalación / producción


Opción A:"pipeline"
Una funcionalidad es desarrollada inicialmente por un desarrollador, testeada de forma local por el 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.
Opcion 2 
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. 

Soporte a Producción

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. 

Opción A: Branching

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)

Opción B

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í.

Comentarios

Entradas populares de este blog

Sacar los números primos de 1-100 en lenguaje C++

¿Que es un operador,y que tipo de operadores hay?

Cómo recorrer una matriz