Funcionalidades de GeneXus que conviene conocer: ChangeSet
Problema: Tengo un conjunto de objetos que modifique pero por algun motivo (el cambio no esta terminado, no se puede subir al server aun, la funcionalidad no puede entrar en produccion, tengo que trabajar en 2 solicitudes en paralelo, etc) no los puedo subir al server por unos dias.
¿Como puedo hacer para que no se mezclen los cambios que ya tengo realizados, con otros con los que tambien tengo que cambiar?.
Solucion: Se pueden usar ChangeSet https://wiki.
Esto es un grupo de objetos modificados, que se pueden agrupar antes de subir al server.
En el ejemplo de arriba, tengo un objeto File que tiene un archivo de control de la propiedad CommitOnExit y otro conjunto de objetos, modificados porque mejoré la modularización del modulo WorkFlow. Claramente son dos cosas que no tienen ninguna relación y no quiero que se vayan en un mismo commit. Por eso, cree 2 Change Sets y agrupe los objetos modificados en esos dos grupos.
Cuando este en condiciones de subir esos objetos al server, será mucho mas fácil para hacer el commit, pues solo elijo los objetos de ese grupo.
Mi deseo es que para próximas versiones de GXServer, se puedan tener etiquetas (o tags) asociados a los ChangeSet y que propaguen hacia los commits, de tal forma de poder crear ChangeSet asociados a un numero de issue o requerimiento y que el mismo pueda luego ser visto en la historia. Ese cambio nos daría una trazabilidad desde los requerimientos hasta el deploy, muy necesario para el manejo de aplicaciones actuales.
Mi deseo es que para próximas versiones de GXServer, se puedan tener etiquetas (o tags) asociados a los ChangeSet y que propaguen hacia los commits, de tal forma de poder crear ChangeSet asociados a un numero de issue o requerimiento y que el mismo pueda luego ser visto en la historia. Ese cambio nos daría una trazabilidad desde los requerimientos hasta el deploy, muy necesario para el manejo de aplicaciones actuales.
En cuanto al último punto, una opción más sencilla de implementación por parte de GX sería que el comentario default del commit sea el nombre del changeset. Si el changeset tiene el #número de issue al principio, lográs el objetivo de asociar los objetos de un commit con un issue.
ResponderBorrarMe parece demasiado fragil, que la trazabilidad desde requerimiento a los objetos modificados en la KB, pasen por un texto libre, que ademas debe usarse para otra cosas, como explicar el cambio.
BorrarA mi me gustaria poder tener etiquetas asociadas a los commits, que puedan cambiarse luego, por ejemplo para saber cuales commits pasaron por revision de codigo o cuales ya estan en produccion, etc.
Es un cambio chico e independiente a lo que hoy existe, que agrega mucho valor y simplifica bastante algunos dolores del ciclo de desarrollo.