GeneXus Server: Escenarios de uso
Estoy tratando de adaptar la metodología de desarrollo al uso de GeneXus Server.Las ventajas de desarrollar en grupo, usando el GXserver, parecen evidentes:
- el grupo de desarrollo va a poder tener KB sincronizadas
- se van a ver los cambios realizados por otros
- se tiene una historia de los cambios en los objetos
- los integrantes del grupo pueden trabajar desconectados y sincronizar por tiempo
La pregunta que me hacía fue: ¿GeneXus Server sirve para todos los casos?
Algunos de los escenarios de uso que hoy tenemos son :
1) KB chica (menos de 1000 objetos)
Dos o tres desarrolladores son los que modifican la KB y la misma está almacenada en el GXServer. No tiene demasiados cambios al dia.
Cada desarrollador tiene una copia local de la KB y tiene una base de datos también local.
Este escenario no tiene problemas. En caso de tener algún problema en la KB local, puedo crear una KB local nueva, bajar todos los objetos y hacer un build all, en un tiempo razonable.
2) KB Medianas (entre 1000 y 5000 objetos)
No analizo esto, porque no tengo estos casos.
3) KB Grande (mas de 5000 objetos) compartida y 6 desarrolladores.
Trabajan sobre la misma KB varias personas, y puede haber hasta 3 personas en forma simultanea sobre la misma. Se hacen muchos cambios al dia. Puede necesitarse arreglos urgentes para instalar en los clientes.
En este caso, la solución pensada es usar el GXServer hosteando la KB y que cada persona tenga una copia local de la KB y de la base de datos. Esto puede ser problemático y enlentecer el desarrollo, pues voy a tener que sincronizar toda la KB cada vez que realice cambios.
En la actividad normal, creo que va a funcionar sin demasiados problemas.
Ventajas.
Todo el mundo va a ver la misma KB sincronizada y la ultima version de los objetos.
Desventajas
Para los arreglos rápidos, cuando se tengan que mandar pocos objetos, puede necesitarse algún ciclo grande de bajar los objetos modificados, hacer el impacto/reorganización y recién ahí poder enviar los cambios. Creo que esto puede ser problemático. Es cierto que podria arreglarse de la forma actual, enviando un export de los objetos y consolidándolos a mano.
Es algo que debería encontrarle una solución mejor.
mejorarse.
4) KB "chicas" con Modelos y un Consolidado (KB grande).
Una de las metodologías de desarrollo, cuando el grupo de desarrollo es grande (mas de 10), es tener KB con módulos que tienen solo los objetos compartidos y los propios de dicho modulo.
Por ejemplo, un ERP, podría estar divido en Contabilidad, Produccion, Stock/Deposito, Ventas, Compras, etc.
En este escenario, la cosa se me complica mucho mas. Es difícil mantener esta forma de trabajo con GXServer, sin duplicar muchos objetos. Podría pasar a trabajarse como en el escenario 3), pero tendríamos varias contras contra lo que hoy se tiene.
El trabajar con KB mas chicas, hace que las personas que recién se incorporan al grupo de desarrollo puedan entender mucho mas rápido la lógica de lo que programan, pues en cada KB hay "pocos" objetos, y la interfaz de un sistema queda mas claro.
Creo que para poder trabajar de esta forma, vamos a tener que esperar a tener algo implementado del objeto módulo en GeneXus.
Tienen algun otro escenario de uso para agregar?
__________________________________________
* Temas que quedan pendientes.
GX server es un producto que aun no esta terminado y esta teniendo muchos cambios en estos días, y tampoco lo he probado en forma intensiva, por lo que no se pueden tener conclusiones definitivas.
Algunas de las dudas que me surgen son:
- Vamos a tener reorganizaciones en el GeneXus Server?
- Se va a poder hacer un build all en el GeneXus Server?
- Vamos a poder copiar datos desde la base de datos del GeneXus Server a la base de datos de los modelos locales, para acelerar las pruebas?.
Hola Enrique,
ResponderBorrarSobre tus dudas: La primer versión que liberemos no va a tener lo del build (lease en su versión extendida create/reorg/build/rebuild/run) en el server, pero hay planes al respecto para más adelante.
Lo del download data no lo había escuchado; pero quizas es para otro post ... cómo manejas hoy eso?
me vienen a la mente dudas relacionadas a terminos que quizas no corresponden o que sí como "procs de carga" "deploy en la nube" "pool de datos para casos de test".
Sobre las desventajas del punto 3:
Cuando hablas del ciclo grande de bajar, etc. Me parece que ese ciclo es igual que hoy, solo que menos propenso a errores humanos. No entendí bien por qué se hace más largo. O sea: si tengo la version local con lo que tiene el cliente, hago el cambio y se lo paso igual que hoy y despues hago commit al server. Si no, obtengo la versión de algun lado (antes de un amigo o una dirección de la intranet y ahora del gxserver). Cómo es bien tu escenario para que se haga más largo ahora?
Armin:
ResponderBorrarLo de download de datos, es para estudiarlo, pero puede estar bueno.
Desventajas de 3).
Supone que hay 15 personas desarrollando. Si tengo las KB modularizadas, y cambio solo 1 KB.
Trabajando con el GXServer, voy a a tener 16 reorganizaciones/build all (15 desarrolladores + el Server).
Si trabajo distribuyendo y consolidando solo los cambios desde una KB, para los objetos no compartidos, voy a tener unicamente 2 reorganizaciones (la de la KB del cambio + el consolidado).
Con ese argumento, creo que el ciclo es MUCHO menor (el esfuerzo total) que usando el server.
Estoy de acuerdo, que sin herramientas adicionales, esto tiene mas trabajo y mayor probabilidad de errores.
Gracias por el comentario.
Enrique, mira que en la operación de "update" los 14 restantes no precisan traerse esos cambios si no les interesa / afecta.
ResponderBorrarY si les interesa, estas en el mismo caso que a mano.
Armin:
ResponderBorrarNo te estoy entendiendo..
Cuando quieran enviar algo al servidor, no van a tener que recibir todos los cambios?
Este comentario ha sido eliminado por el autor.
ResponderBorrarEnrique, creo que ahora entendí la confusión: No se precisa haber hecho update para poder hacer commit. O sea:
ResponderBorrarSi vos modificas el objeto A y haces commit, yo para hacer commit del objeto B no preciso hacer update seleccionando A.
O sea, la respuesta a tu última pregunta es "No, no tienen que recibir todos los cambios".
y gracias por responder!
Saludos, Armin
FAQ by Enrique and armin :)
ResponderBorrarOtro caso que me imagino es el siguiente.
ResponderBorrarTengo un grupo de 10 personas trabajando cada uno con KB locales.
A ese grupo lo llamaré "Línea de Trabajo".
Para ese grupo se encuentra una KB en GeneXus Server contra la cual las 10 personas sincronizan su KB Local.
Cada persona de la línea trabaja conectad/desconectado o geográficamente distantes.
A nivel de la línea, existe una persona responsable por la KB en el Server.
Cada tanto tiempo, la KB en el Server se sincroniza contra una KB Centralizada en otro Server (KB Centralizada).
El responsable de la KB en el Server de la línea medirá el impacto y será el responsable de la propagación de los cambios de la línea (es posible tomar la decisión de que cosas sincronizar, por lo que será el responsable de tomar esas decisiones que afectarán a toda la línea de trabajo).
La KB Server de la línea sincroniza contra una KB Consolidada, en donde todas las otras líneas de trabajo (que trabajan contra otros módulos del sistema) también sincronizan.
Luego esa KB Server (Centralizada) en donde consolidan todos las líneas, se sincronizará contra la KB final institucional en donde alguien (un sector) velará por la integridad de todo el producto (Un encargado de la KB "institucional").
Este sector se encargará de ver los impactos y los cambios a nivel de todos los módulos a efectos de identificar colisiones o problemas no detectados por aquellos que solo ven "su módulo" (el árbol y no el bosque).
La arquitectura sería algo como una estrella, en donde saliendo de las líneas cada KB Server se sincronizarían contra una KBServer central la cual se sincronizaría contra otra KBServer final.
Se que suena muy burocrático, pero sucede que es la única forma de poder lidiar con la complejidad.
Cuando un producto es muy grande, y la cantidad de personas "tocando" en la KB es muy grande, la probabilidad de problemas por descuidos es mucho mayor (una arquitectura basada en dividir para conquistar y en la desconfianza ya que el error humano es inevitable).
Esto además asegura que en sucesivas etapas las cosas "no se escapen", el líder de la línea de trabajo podrá verificar los cambios que se realizan sobre el módulo del producto ( y podrá controlar los cambios que hacen personas con menor conocimiento del mismo).
En el momento que el líder libera los cambios con confianza a la KB Server Centralizada, el encargado de esa KB podrá controlar las cosas que implementan todos, y podrá comparar los impactos contra la KB centralizada final (Institucional).
Algo que podría minimizar tanta burocracia: Incorporar análisis de impacto y reglas de negocio en GeneXus Server (Estoy esperando que salga el soporte de Extensiones y que sea posible automatizar cosas detrás del Server para comenzar a jugar un poco con eso).
Los casos que menciona Enrique, requieren también de personas que velen por el producto, cuando un producto es pequeño, como menciona Enrique, el conocimiento es mas simple de manejar, por lo tanto la posibilidad de errores es menor, sin embargo cuando la complejidad de los módulos va en aumento, se tiene que ir hacia una metodología "basada en la desconfianza" para poder velar por la calidad y confiabilidad de los cambios realizados.
Me queda la duda de que tan escalable y performante sea una arquitectura así.
En metodologías ágiles cuanto más rápido un cambio más rápido se detectan los errores y más rápido se trabaja en solucionarlos.
Para poder lograrlo hay que trabajar más en automatizar, incorporar mayor detalle de análisis de impacto y dar herramientas que tomen control de las decisiones (Extensiones?).
Artech viene realizando un excelente trabajo con GeneXus X/Ev1 y su Server, especialmente en lo referente a la posibilidad de crear extensiones (y con las mismas tomar control del proceso de desarrollo).
Soy uno de esos que crearon muchas herramientas por fuera de GX (GXPublic y generando XPZ's), por lo que el nuevo abanico de posibilidades con Extensiones y el acceso real a todo el conocimiento abre las puertas a nuevas posibilidades.
David:
ResponderBorrarNo entendi bien tu esquema.
Tendrias:
KB INSTITUCIONAL (es la version estable/instalable de la consolidada)
KB CONSOLIDADA (formado con)
---KB LINEA1
---KB LINEA2
---KB LINEA3
Y a su vez cada KB LineaX estaria armada con 10 personas programando.
Las dudas
KB CONSOLIDADA "es igual" a la KB INSTITUCIONAL?.
Si fuera asi, seria parecido al esquema 3, pero nosotros tenemos solo una LINEA.
Si no es asi, quiere decir que no entendi bien.
Esto viene por el lado de montar Multi-Stage Continuous Integration con GeneXus Server.
ResponderBorrarEs una mezcla del caso 3 y el caso 4.
No quiero ponerme en detalle a explicar el tema porque realmente se confundirían mucho más las cosas.
Para que se entienda un poco más, no hay como verlo en otros lados (y con imágenes).
http://en.wikipedia.org/wiki/Multi-stage_continuous_integration
Les recomiendo las lecturas de los artículos de referencia.
Imagen de ejemplo de AccuRev http://www.accurev.com/images/mutltstage-continuous-integration.gif
Cosas que hay que buscar implementar en las KB's Server, es la posibilidad de sincronización parcial (Solo sincronizo lo que afecta a mi módulo).
Las KB Server de las líneas son KB Modulares (no necesariamente 1 KB para 1 línea, pero si 1 KBServer para cada línea).
La Consolidada tiene la sumatoria de todas las KB Modulares y la Institucional es la KB que pasó todos los pasos de Calidad (QA).
Voy a ver si puedo hacerme de un tiempo para hacer unos diagramas y explicar en mi blog un poco de cómo podría ser posible montar Multi-Stage Continuous Integration con GeneXus Server.
David:
ResponderBorrarCon las imagenes queda mas claro.
La ventaja de la intergración continua es algo muy conveniente. Se van a necesitar algunas extensiones para lograrlo.
Quedo a la espera de ampliaciones en tu blog.
Sobre las dudas:
ResponderBorrarExtendiendo solo un poco lo que dice Armin en el primer comentario, en realidad estamos trabajando en un modulo con el cuál sea fácil la implementación de Continous Integration. En un esquema de CI en general no es conveniente que las operaciones de Build, Reorgs, etc se hagan sobre el propio server. En esencia el módulo de Build trabaja sobre otra KB Cliente y no directamente sobre la KB Server la cuál simplemente oficia de repositorio.
Saludos,
Gastón
Dudas!
ResponderBorrar¿Se puede utilizar “GX Server U3” con “Gx X Ev1 U2 y U3” simultáneamente?
¿Conversa bien un modelo Gx X Ev1 U3 con un Gx Server U2?
Espero comentarios!
Saludos.
Anonimo:
ResponderBorrarEsa duda no te la se responder. Creo que si, pero mejor preguntaselo a soporte en Artech.
Enrique
Buenas tardes.
ResponderBorrarSoy un desarrollador independiente, he podido comprar licencia para desarrollar en GX Ev3, pero me estaria faltando podes versionar y guardar los cambios en GXServer, mi pregunta es ¿Si alguien tiene licencia que revenda?. Espero su respuestar . gxdesarrollos@wbtinfo.com ...... Saludos