Aunque parezca un tema técnico, es un tema funcional, de negocio, de arquitectura, de sistemas, financiero y por supuesto, también es técnico.
¿Cómo hemos llegado a esta malinterpretación, en el sector del software?. Como siempre las consultoras tienen mucha culpa de esto, al hablar erróneamente unas veces o sin conocimiento real en otras sobre este asunto, porque su negocio realmente es otro diferente al software.
Si buscamos en internet "entornos de software", veremos que el orden preconcebido siempre es DES TEST PRE y PRO.
La explicación siempre es la misma:
Entorno DES: Es para desarrollo, etcétera., .... totalmente de acuerdo en todo
Entorno TEST: Es para hacer pruebas, test, debe ser idéntico a PRO para que las pruebas sean idénticas, salvo los datos que deben estar anonimizados para evitar errores y de paso cumplir con la ISO
Entorno PRO: el entorno de trabajo, donde entra y trabaja todo el mundo
Hemos dejado para el final el uso que se hace del entorno PRE. Porque aquí viene la malinterpretación, bajo nuestra opinión .Que con el paso del tiempo, una gran mayoría, han dado por bueno.
Vamos a intentar explicar el por qué de esa malinterpretación, apoyado en un producto que conocemos muy a fondo, desde hace más de 12 años. Como es el producto MICROSOFT DYNAMICS CRM.
En nuestra opinión, esa gran mayoría que usan DES TEST PRE PRO, entienden el entorno PRE como el "previous to PRO". Y aquí viene la primera pregunta:
Si usamos DES TEST PRE PRO, ¿para qué sirve el entorno PRE?
La respuesta siempre es la misma: el entorno PRE debe ser idéntico a PRO y sirve para hacer las últimas pruebas antes de subirlo.
Desde WHY Dynamics volvemos a preguntar: ¿pero entonces para qué sirve TEST?
La respuesta siempre es la misma: el entorno TEST es sólo para hacer pruebas.
Desde WHY Dynamics asumimos que puede ser una forma de trabajar (aunque cuasi duplicada) y entonces preguntamos: pero entonces cuando de PRE pasas a PRO y aparecen fallos en PRO. ¿Cómo los resuelves, cuanto tiempo te lleva resolverlo, cuantos reintentos y cuantas interrupciones con errores a los usuarios del sistema de PRO?
Aquí la verdad, las respuestas son variopintas
Volviendo al entorno PRE visto como "PREvious to PRO" podemos observar que los beneficios son casi nulos.
Por lo que resulta normal, que muchas empresas no tengan entorno PRE ó tengan un entorno PRE pero no un entorno TEST o a los que le sobra el dinero tengan DES TEST PRE PRO, a sabiendas de lo dicho anteriormente que el entorno PRE bajo esta arquitectura DES TEST PRE PRO, da nulos beneficios
Ahora vamos a ver la arquitectura de entornos que usamos en WHY Dynamics, en nuestros proyectos basados en el producto MICROSOFT DYNAMICS CRM y los grandes beneficios que aporta esta arquitectura.
ARQUTECTURA DES TEST PRO PRE
La arquitectura DES TEST PRO PRE, donde el entorno PRE lo definimos como "PREvious version in PRO".
El entorno DES: sigue siendo igual para desarrollo,... que en el modelo DES TEST PRE PRO
El entorno PRO sigue siendo igual el entorno de trabajo, donde entra y trabaja todo el mundo,... que en el modelo DES TEST PRE PRO
El entorno TEST: sigue siendo igual para test,.....que en el modelo DES TEST PRE PRO. Sin embargo, debe ser idéntico a PRO. En cuanto a integraciones, características técnicas,..etc porque una vez validado irá al entorno PRO cuando le toque el turno.
Pues antes de pasar del entorno TEST al entorno PRO. Debemos pasar del entorno PRO, lo que haya, al entorno PRE (ver imagen a abajo)
El entorno PRE: (que no hace falta que sea muy grande) es un entorno de backup, bajo esta identidad de "PREvious version in PRO".
Por tanto, si luego cuando despleguemos del entorno TEST al entorno PRO aparece algún fallo. Hacer rollback total o parcial es cuestión de minutos. frente a la arquitectura DES TEST PRE PRO donde es variopinto, desordenado y poco medible, en caso de necesitar hacer rollback por errores en el entorno PRO.
Por ejemplo, cuando aparece un error en un webresource, pues se restaura del entorno PRE al entorno PRO sólo ese webresource.
Otro ejemplo, cuando aparece un error en un workflow o en un plugin o en un javascript, pues se restaura del entorno PRE al entorno PRO sólo ese elemento y todo sigue funcionando como estaba haciendo hasta ahora. Es sencillo.
Y de esta manera, por un lado los usuarios se ven afectados muy poco tiempo y por otro lado, el equipo de soporte puede empezar a investigar tranquilamente.
Y una vez, encontrado el error, corregirlo y volver a pasar por el entorno TEST y cuando esté validado, se vuelve a pasar lo que haya en el entorno PRO al entorno PRE y finalmente, desplegar la corrección desde el entorno TEST al entorno PRO.
Esta es la arquitectura que utilizamos en nuestra empresa WHY Dynamics y que es extrapolable a otros sistema de software. Dando unos beneficios y seguridad muy altos, al ciclo de implementaciones.
Esperamos que haya sido de vuestro interés y respetamos que cada uno lo haga como estime oportuno.
Nuestro objetivo al compartir la arquitectura que utilizamos en WHY Dynamics en este artículo, es poner nuestro granito de arena en la mejora de las implementaciones de Software