Instalación de objetos cambiados en grandes aplicaciones GeneXus.
Hay aplicaciones que son mas fáciles de instalar que otras. También influyen mucho en la forma que se instala una aplicación los procesos que se tengan definidos en la organización en la cual se instalan.
En el entorno que me muevo habitualmente, la forma de trabajo es la siguiente :
- Los usuarios funcionales definen los requisitos o requerimientos de la aplicación.
- Un grupo de desarrollo diseña y programa la solución y se realizan pruebas técnicas
- El grupo de usuarios que fija los requerimientos debe dar la aprobación que la aplicación cumple con los requisitos.
Para lograr esto, se tienen los siguientes ambientes:
- Desarrollo. Donde los desarrolladores GeneXus programa y consolidan su trabajo
- Pre-Producción. Donde los usuarios expertos realizan las pruebas funcionales y aprueban el pasaje a producción.
- Producción. Donde se ejecuta la aplicación. Los desarrolladores no tienen acceso a este ambiente, o algunos solo tienen acceso para realizar consultas.
Un ejemplo sencillo de una secuencia de Envios desde DESARROLLO a PREPRODUCCION.
Si los envíos se aprueban en orden, pueden pasarse en orden también desde PREPRODUCCION a PRODUCCION, sin tener mayores problemas, pues todos los objetos y las inicializaciones se harán igual que en PREPRODUCCION.
Ahora, que sucede, cuando un ENVIO se demora en su aprobación?
La realidad suele ser bastante mas terca de lo que realmente queremos y a pesar de intentar instalar todo en el mismo orden en que fue generado, muchas veces esto no es posible, por urgencias o porque las pruebas a realizar llevan mucho tiempo o se necesita alguna ley/decreto o suceso para que una funcionalidad pueda entrar en produccion.
Supongamos que por un momento, instalamos primero el Envio3, y luego el Envio1 y el Envio2.
Lo que va a provocar, es que los cambios realizados en el Objeto1 se pierdan (si usamos la versión del Objeto1 al momento de enviar el Envio1) o que la funcionalidad del Envio3 pueda tener problemas, pues falta alguna inicialización o cambio realizado en los Envios1 y 2.
Cuando el grupo de trabajo es numeroso, la problematica de la instalacion/aprobacion y las dependencias pasa a ser un tema interesante.
Por ahora, y obviando algunas dependencias como son las tablas u otros objetos indirectos (como SDT, atributos, etc) nosotros llevamos un registro de los objetos cambiados por Envio y la fecha de los mismos.
Esto nos permite contestar las preguntas
- Cuales son los Envíos No instalados en PRODUCCION?
- Cuales son los Envíos No aprobados en PREPRODUCCION?
- Cuales son los Envíos que debería instalar antes de un Envio dado (los que mande antes y comparten objetos)?
- Cuales son los Envíos posteriores que ya instale y comparten objetos con un Envio dado? (estos los debo reinstalar)
A pesar de tener estas herramientas, igual hay casos que se escapan y cometemos errores. El tema de poner en producción lotes de objetos, es bastante complejo.
Como lo solucionan en sus empresas?
PD: Para simplificar, no tome en cuenta otras dependencias entre los envios, como son las tablas utilizadas por los objetos, los programas llamados por los mismos, los script necesarios, metadatos o valores de parametros, etc.
Excelente Enrique!!
ResponderBorrarMe parece excelente el aporte de comunicar metodologías, así como la oportunidad de plantear ideas para que sean tomadas por la comunidad.
Te cuento el "habitual" mío y mi visión de cómo podría ser.
Se busca dividir el problema en líneas de trabajo (o quipos de trabajo), los cuales son especialistas en cada tema (módulo del sistema u operativa), ese equipo está conformado por funcionales y técnicos, los cuales trabajan en el relevamiento de requerimientos (sean mediante reportes de correcciones por el cliente, o sea mantenimiento, o relevamiento de mejoras o nuevos desarrollos).
La parte de diseño y programación lo realiza la gente del equipo especializado, luego pasa por la aprobación del cliente o funcional si es un requerimiento interno de mejora (en caso de corrección de error es sin aprobación, se corrige lo antes posible según el planning del equipo en base a prioridades).
Cada equipo tiene su ambiente de desarrollo (en ocasiones el ambiente es por cliente), en ese ambiente se hace la parametrización y pruebas en modo Testing, luego de que todo está correcto pasa a consolidarse en "repositorio consolidado" y el resultado de ese repositorio se prueba en el mismo ambiente (eliminando los objetos testing y dejando los finales), si las pruebas no son correctas se soluciona el problema (si fue mala documentación o cosas que no se enviaron a consolidar, etc).
Si está correcta la prueba final, el equipo hace la liberación de los cambios al cliente, el cual tiene un ambiente de preproducción en donde él hace el ciclo completo según la documentación para verificar que lo enviado y lo desarrollado es correcto, antes de enviarlo a producción.
El tema de la "desincronización" de los ambientes dada la secuencialidad de los envíos es todo un tema, ya que si un envío no se aplica y existen dependencias funcionales en sucesivos envíos el caos puede ser importante.
Una recomendación que hacemos para cuando el nivel de envíos por desarrollo de nuevas funcionalidades es hacer luego de que todos los envíos fueron aplicados una última prueba en preproducción de todos los envíos, para cerciorarse que algún envío no esté ocasionando inconsistencias (no siempre todos los envíos llegan a pre producción, el cliente en ocasiones cambia de parecer o nunca aprueba el pasaje de algo por diferentes razones).
Mantener sincronizado desde Tablas, programas y datos es todo un problema a solucionar.
(continua...)
Actualmente trabajo en varias herramientas que intentan subsanar todos estos problemitas, permitiendo encapsular de forma más simple el pasaje de ésta información entre los diferentes ambientes.
ResponderBorrarHoy se tiene traza de cada "paquete de entrega" con su respectivas versiones de fuentes, así como que script's tablas o datos fueron enviados, permitiendo alguna posibilidad de "rollback" en caso que algún cambio no quiera aplicarse (cosa que no sucede seguido, pero en alguna oportunidad sucedió).
Generalmente se trabaja de forma evolutiva aplicando cambios y evolucionando lo implementado hasta llegar a lo deseado.
Con respecto al estado de los envíos y si fueron puestos o no en producción, cuando pasan a control del cliente, es parte del cliente la responsabilidad de la parte de QA y pasaje por preproducción a producción, nosotros solo tenemos un "OK" de que preproducción funcionó bien, y perdemos control de cuando ellos lo ponen efectivamente en producción.
Nuestro desafío es lograr controlar luego qué versiones de qué cosas tienen en producción para brindar correcciones o adaptaciones (o updates).
Es por ello que se debe de trabajar en un sistema de versionado sobre los objetos y tablas (inclusive de parámetros, imágenes, css's, javascript's y archivos de configuración?) para poder tener control de qué es lo que realmente llegó a producción y cómo lograr cerrar el Gap entre lo que el cliente tiene en producción y lo que nosotros entregamos (y las evoluciones del sistema que existieron en paralelo).
Nuestro desarrollo es atípico, no manejamos versionado por módulos, ya que todo en el sistema es sujeto a adaptaciones de todos los clientes y cada cliente puede o no querer tener desde actualiación por funcionalidad a correcciones puntuales sin tener que actualizar módulos enteros o el sistema completo.
Sin embargo nuestro proceso es altamente ágil, proporcionando a nuestros clientes tiempos relativamente muchos más cortos a lo que sería una creación de versión por módulo, nuestro sistema sería algo así como un sistema de Hotfix o Paquetes acumulativos, teniendo claro snapshots a fechas con "Versión con updates acumulados".
Otro problema es cuando la aplicación es multiplataforma como la nuestra (mix de lenguajes y base de datos) y tienes que asegurar que la misma versión del objeto/tabla esté para todas las plataformas de todos tus clientes.
(continua...)
Es así que también existen herramientas encargadas de todo el ciclo, asegurándose que todo esté disponible para cada ambiente de desarrollo en cada plataforma (claro que el Testing funcional sobre un requerimiento se prueba en ese momento fuertemente en la plataforma del cliente que lo solicitó, pero, nos aseguramos que esa mejora o ajustes también estén en las otras plataformas disponibles).
ResponderBorrarComo menciona Enrique, a pesar de herramientas, documentación y un proceso que ayude tanto a quien implementa como al cliente, se escapan cosas y cometemos errores (las herramientas automatizadas ayudan a que el error humano disminuya).
El tema de poner en producción lotes, realmente es muy complejo, algunas metodologías ágiles apuntan a que directamente los cambios se prueben en producción y se arreglen sobre la marcha, pero lamentablemente ese tipo de cosas solamente son posibles en sitios como facebook o twitter, en sistemas de misión crítica no se puede jugar de esa forma (mucho dinero, e inclusive vidas pueden depender del correcto funcionamiento del sistema).
Si las herramientas tienen en cuenta la combinatorio de objetos y la incidencia en el comportamiento del sistema, es posible tener control sobre qué se afecta en caso de que se aplique o no un envío, herramientas en torno a gxtest permitirían tener mayor conocimiento sobre la parte "funcional" de las dependencias, luego en el versionado de los objetos se podría tener control sobre "la parte dura", dependencias básicas de funcionalidad (tablas, parámetros, etc).
Con esto se podría tener herramientas de análisis que ayudarían tanto para el mantenimiento como para las puesta en producción de n envíos a pre y producción.
David:
ResponderBorrarGracias por el aporte!. El deployment de aplicaciones de esta forma, es muy ventajosa para los clientes pues tienen los arreglos o nuevas funcionalidades mas rapido que con otras metodologias, aunque se complica la administracion de que es lo que se instala y lo que no debe instalarse.
Creo que el test automatizado tiene una importancia muy grande en este esquema. Tambien el armado de ambientes de test en forma facil para la realizacion de pruebas.
El deployment de aplicaciones, es algo que en al comunidad Genexus siempre ha estado relegado, dandosele poca importancia. Supongo que el motivo es que la mayoria de las aplicaciones son faciles de instalar por su tama#o.
En fin, por suerte, queda mucho por hacer y mejorar.
Es una oportunidad para quien quiera hacer una herramienta comercial que ayude en el deployment.
Muy bueno el post y el aporte de David.
ResponderBorraruna pregunta, en otras plataformas, que herramientas comerciales que ayuden con el deployment hay? las hay? tienen los mismo problemas (tiendo a pensar de que si)
Saludos
Matías
Matias:
ResponderBorrarCreo que el problema de saber que es lo que hay que pasar a produccion (en el caso de desarrollo tradicional, son los fuentes), es mas o menos similar, pero cuentan con herramientas de manejo de versiones que pueden ayudar a alivianar el problema.
Con respecto a las herramientas propias de deployment, no soy un especialista, pero conozco algunas. Estaria bueno que alguien que programe con .NET, Ruby o Java, contaran como hacen ellos para hacer el deploy de su aplicacion.
Hay alguna restriccion por la que no ponen nombres de herramientas? Les agradeceria que me mencionen un par para investigar al respecto. Muchas gracias. Saludos. Matias
ResponderBorrar