"Usabilizando" Genexus (Reorganizaciones Parciales)
De la serie "Usabilizando" GeneXus
Creo que este problema se explica solo, con un ejemplo.
Una KB GeneXus de unos 4000 objetos, que tiene un modelo de prototipo y otro de producción.
a)Es necesario programar un nuevo módulo, que implica cambiar 10 transacciones (cambian su estructura y codigo) y algunos objetos adicionales (procedimientos, webpanels, etc). La programacion / pruebas / documentacion van a llevar una semana.
b) Como Murphy trabaja para el enemigo, es común que aparezca durante esa semana, algún cambio URGENTE e impostergable (los mas comunes son algún decreto del gobierno), que obliga a la realización de algún cambio menor en el modelo de datos, que obliga a cambiar alguna otra transaccion del modelo de diseño.
Esto plantea un dilema
Si hago el impacto, va a llevar a producción transacciones que aun no estan listas (las del cambio a)
Si no hago el impacto, no puedo llevar los cambios que necesito para el cambio b.
En cualquiera de las dos opciones, estoy dejando los objetos que de produccion, en un estado no deseado.
Existen alternativas, para minimizar este problema, pero todas son complicadas. La mas sencilla es tener una KB para desarrollo y otra para produccion. De esta forma puedo elegir que transacciones distribuyo y consolido.
Tiene la contra de que se agregan varios pasos que llevan tiempo, hay que chequear que los indices que cambian de nombre, etc.
Podria solucionarse si se pudieran hacer Impactos Parciales, o sea elegir cuales son las transacciones que se quieren impactar (o llevar a produccion), de forma de poder hacer reorganizaciones parciales, tal como se pueden hacer hoy el impacto de objetos.
Otra opción seria poder hacer las modificaciones de la estructura de las transacciones en modelos que no sean de diseño, para poder realizar estos cambios.
Creo que este problema se explica solo, con un ejemplo.
Una KB GeneXus de unos 4000 objetos, que tiene un modelo de prototipo y otro de producción.
a)Es necesario programar un nuevo módulo, que implica cambiar 10 transacciones (cambian su estructura y codigo) y algunos objetos adicionales (procedimientos, webpanels, etc). La programacion / pruebas / documentacion van a llevar una semana.
b) Como Murphy trabaja para el enemigo, es común que aparezca durante esa semana, algún cambio URGENTE e impostergable (los mas comunes son algún decreto del gobierno), que obliga a la realización de algún cambio menor en el modelo de datos, que obliga a cambiar alguna otra transaccion del modelo de diseño.
Esto plantea un dilema
Si hago el impacto, va a llevar a producción transacciones que aun no estan listas (las del cambio a)
Si no hago el impacto, no puedo llevar los cambios que necesito para el cambio b.
En cualquiera de las dos opciones, estoy dejando los objetos que de produccion, en un estado no deseado.
Existen alternativas, para minimizar este problema, pero todas son complicadas. La mas sencilla es tener una KB para desarrollo y otra para produccion. De esta forma puedo elegir que transacciones distribuyo y consolido.
Tiene la contra de que se agregan varios pasos que llevan tiempo, hay que chequear que los indices que cambian de nombre, etc.
Podria solucionarse si se pudieran hacer Impactos Parciales, o sea elegir cuales son las transacciones que se quieren impactar (o llevar a produccion), de forma de poder hacer reorganizaciones parciales, tal como se pueden hacer hoy el impacto de objetos.
Otra opción seria poder hacer las modificaciones de la estructura de las transacciones en modelos que no sean de diseño, para poder realizar estos cambios.
Comentarios
Publicar un comentario
1) Lee el post
2) Poné tu opinión sobre el mismo.
Todos los comentarios serán leidos y la mayoría son publicados.