Historia de reorganizaciones
En el foro de la rocha, se està conversando sobre la conveniencia o no de guardar dentro de la KB la historia de las reorganizaciones. Gustavo escribio un buen post sobre el tema. Justamente me encuentro trabajando en un proyecto de un cliente, en el cual han perdido alguna(s) reorganizaciones y mi tarea es reconstruir lo perdido y a lo mejor por eso el tema me tiene mas sensibilizado.
Basicamete existen dos posiciones.
a) Guardar la historia de las reorganizaciones y poder ejecutar las reorganizaciones secuencialmente.
b) Tener algun mecanismo de guardar versiones y poder generar la reorganizacion necesaria para que se sincronicen dichas versiones.
Desde mi punto de vista, ambas son validas y ambas necesarias.
La historia de las reorganizaciones, son NECESARIAS. En muchos lugares es obligatorio guardar dichas reorganizaciones, para saber cuando se cambio algo. Por lo tanto si GeneXus no ayuda a guardar la historia de las reorganizaciones, cada quien que lo necesite lo seguirà haciendo en forma artesanal como hasta ahora.
Todavia no hay (o no tengo yo) informacion sobre como sera el manejo de versiones y como poder generar una reorganizacion entre dos versiones, pero supongo que es posible y va a funcionar bien.
Lo que yo me imagino, es que tendremos un mecanismo de trabajo donde estaremos haciendos muchos cambios chicos. En determinado momento se decidira que el resultado de la reorg, es "la postalina". En dicho momento, compararemos la version "de produccion", con "los ultimos cambios" y ahi se generarà la reorganizacion deseada.
Dicha reorganizacion HAY que testearla y guardarla, por lo menos en nuestra forma de trabajo.
Seria bueno, poder contar con alguna ayuda, que permitiera NO PERDER reorganizaciones y a su vez organizar el trabajo en forma mas facil.
"Si en el campo de batalla, el mapa no coincide con el terreno, guìese por el terreno".
Es una frase (no textual) de un manual de guerra ingles. No se porque me vino a la mente, pero a los ingleses en el tema de la guerra, no hay que tomarlos a la ligera.
Basicamete existen dos posiciones.
a) Guardar la historia de las reorganizaciones y poder ejecutar las reorganizaciones secuencialmente.
b) Tener algun mecanismo de guardar versiones y poder generar la reorganizacion necesaria para que se sincronicen dichas versiones.
Desde mi punto de vista, ambas son validas y ambas necesarias.
La historia de las reorganizaciones, son NECESARIAS. En muchos lugares es obligatorio guardar dichas reorganizaciones, para saber cuando se cambio algo. Por lo tanto si GeneXus no ayuda a guardar la historia de las reorganizaciones, cada quien que lo necesite lo seguirà haciendo en forma artesanal como hasta ahora.
Todavia no hay (o no tengo yo) informacion sobre como sera el manejo de versiones y como poder generar una reorganizacion entre dos versiones, pero supongo que es posible y va a funcionar bien.
Lo que yo me imagino, es que tendremos un mecanismo de trabajo donde estaremos haciendos muchos cambios chicos. En determinado momento se decidira que el resultado de la reorg, es "la postalina". En dicho momento, compararemos la version "de produccion", con "los ultimos cambios" y ahi se generarà la reorganizacion deseada.
Dicha reorganizacion HAY que testearla y guardarla, por lo menos en nuestra forma de trabajo.
Seria bueno, poder contar con alguna ayuda, que permitiera NO PERDER reorganizaciones y a su vez organizar el trabajo en forma mas facil.
"Si en el campo de batalla, el mapa no coincide con el terreno, guìese por el terreno".
Es una frase (no textual) de un manual de guerra ingles. No se porque me vino a la mente, pero a los ingleses en el tema de la guerra, no hay que tomarlos a la ligera.
Es un hecho que si tengo la versión 1 de una aplicación y la versión 2, la reorganización que pueda surgir entre ellas no se perderá a menos que alguna versión se pierda.
ResponderBorrarSi perdiera el código generado de la reorganización podría reconstruirlo salvo ... salvo ... salvo que haya sido modificado manualmente o se le haya agregado código de usuario en los lugares previstos (o no previstos).
En este caso, que creo que (al menos para ustedes) es bastante común, sería necesario salvar el código de la reorganización.
Gustavo:
ResponderBorrarSiempre es un gusto tener un comentario tuyo!.
Aun no entiendo bien como van a funcionar las versiones. Me temo que en lugares donde tengas una KB que trabaje mucha gente, no va a ser facil guardar las versiones, pues la gente se olvida de "sacar la foto". Sin embargo, creo que es mas facil guardar que reorganizaciones se fueron haciendo y con eso es mas facil reconstruir la historia.
Como dije antes, me gustaria entender y probar como se pueden usar las versiones en las KB donde trabajen varias personas y despues opinare con mas argumentos.
Lo que si es cierto que cualquier cosa que ayude a que no se pierdan reorganizaciones va a ser apoyada por mi, con todo ahinco.
Saludos y gracias,
Enrique
La foto se saca en un único lugar y, diría que quien lo hace es la misma persona o grupo que se encarga de la reorganización (armarla, probarla, etc.). Quisiera pensar que esta persona o grupo no se va a olvidar de sacar la foto :-).
ResponderBorrarYo pienso que las versiones de una aplicación estarán en una KB "centralizada" (no es un nombre felíz pero sirve). Las KBs de desarrollo tendrán normalmente UNA versión de esa aplicación.
Si como desarrollador tengo que trabajar simultáneamente en dos versiones de la misma aplicación podría optar por tener una KB por versión o varias versiones en la misma KB. Creo que sería una cuestión de costumbre.