En la versión Beta 2 de la Rocha se incluyó algo llamado "KB Versions".
Mi sensación sobre el tema es que el esquema de "versionado" quea permite GX Rocha en su Beta 2 sienta una base muy versátil que permite mantener "hilos de desarrollo" independientes, versiones diferentes por cliente, por ambiente, etc. Todo integrado en una misma KB lo que lo hace mucho más práctico y potente.
Está explicado en el wiki, de todos modos acá mi interpretación "sui generis" del asunto que pueda servir como "introducción" al tema.
Disclaimer: Aunque los conceptos son iguales para todo el mundo, este post está orientado especialmente para quienes vienen de versiones anteriores de GX ya que en ciertos momentos se hace un paralelismo entre los conceptos actuales y los de versiones anteriores.
Cuando desarrollo una KB basicamente tengo dos cosas: objetos y environments
Los objetos son las transacciones, webpanels, dominios, atributos, documentos, etc.
Los environment refieren a las propiedades como base de datos utilizada, información de conexión a la misma, propiedades de ejecución, lenguaje, etc.
Suele suceder que una misma aplicación (grupo de objetos) requiere generarse para diferentes "environments", por mencionar ejemplos: diferentes DBMS, diferentes plataformas: en Java, .NET, Ruby o cualquier otra propiedad del estilo.
Eso en versiones anteriores de GeneXus se resolvía agregando un modelo porque era el único método para tener diferentes "sets" de valores de las propiedades. Así por ejemplo tenía un modelo .NET y otro Java o un modelo con SQL Server, otro con MySQL y otro con Oracle, etc.
En la Rocha, cuando se crea una KB, ya se establece un environment default y a su vez se pueden crear nuevos "environments", se puede ver el proceso en este video:
En todo momento tendré un "environment activo" que en definitiva es lo que gobierna para qué plataforma, DBMS, lenguaje, etc se está generando.
En este otro video se puede ver como activar (set target as) un environment:
Es decir, un modelo era un conjunto de objetos + un environment, eso en la Rocha no es más necesario y solo definiendo un nuevo "environment" es suficiente.Llamemos a esto (Objetos + uno o más environments) un "branch", digamos que una "linea de trabajo" dentro de la KB. Armin dabe un ejemplo de uso del tema en su blog.
Como comentaba antes, toda KB, ni bien se crea, tiene un "branch" inicial conocido como "trunk". No tiene nada de especial, solo que es el "tronco" de la KB y que su nombre es el propio nombre de la KB.
Se puede trabajar sobre ese branch y nada más o a su vez se pueden derivar diferentes "branches", es decir armar otro conjunto de "objetos+environments" que tienen un objetivo especifico.
Por ejemplo, en un momento se trabajará sobre un grupo de objetos a entregar en Marzo/2008 (llamémosle: corto plazo) y a la vez se está trabajando en una re-ingeniería de la KB que estará finalizada en Setiembre/2008 (llamémosle: mediano plazo).
Del mismo que hay una perspectiva "evolutiva", puede haber una perspectiva "por cliente" o por el motivo que sea que requiera tener más de un branch (linea de trabajo) sobre la misma KB.
Dentro de una KB siempre se está trabajando sobre un "branch" activo, digamos que en el ejemplo estaré trabajando sobre el "branch corto plazo" o el "branch largo plazo", que en definitiva es un conjunto de objetos en un "estado A" y que tiene asociado un conjunto de "environments" (set de valores de propiedades).
En este video se muestra como crear y activar branches:
De un branch, además de otro branch, se puede derivar una versión.
Creo que la manera más fácil de entender una versión es: una "foto" del branch (objetos + environments) del cual se deriva. Es decir, quedan los objetos en un "estado A", y todos los environments en "estado A". Todo read-only. Similar a un backup.
Volviendo al ejemplo, habiamos derivado el branch "Corto plazo" que tenemos que entregar en Marzo/2008, entonces el 6/Dic/07 decidimos liberar la "Beta 2" de nuestra aplicación. Lo que hago es "activar" ese branch "Corto plazo" y derivar de él una versión, llamémosle "Beta2". Lo mismo podría hacer si fuera a hacer una entrega a un cliente, derivar una versión significa "congelar" lo que entrego al cliente.
En este video se puede ver como crear una versión a partir de un branch:
Mis usuarios testearán dicha versión y seguramente reportarán problemas, entonces podré corregirlos en el branch "corto plazo" y en algún momento derivar la version "beta 2.1".
Sin embargo si he realizado modificaciones en el branch "Corto plazo" que no quiero incluirlas en este momento, puedo derivar un nuevo branch de la versión "Beta 2" y realizar las modificaciones en el mismo.
En el siguiente video se muestra como derivar una versión de un branch:
Mientras los usuarios prueban la Beta 2, a su vez se continua trabajando en el largo plazo donde hago cambios más sustanciales.
En definitiva, con los "branches" y "versiones" puedo tener varias lineas de trabajo a la vez sobre la misma KB y en cada momento decidir con que branch trabajar. En el ejemplo está con una perspectiva "evolutiva" pero las necesidades pueden variar de acuerdo a las circunstancias de cada equipo, eventualmente preciso "branches/versiones" por cliente o por el motivo que fuera.
Volviendo a lo del principio, el esquema de "objetos", "environments" (configuraciones), "branches" (objetos + configuraciones que representan una linea de trabajo) y "versiones" (objetos + configuraciones que representan una foto), sienta las bases para trabajar con diferentes metodologías (más o menos ágiles, más o menos flexibles, lo que cada grupo de trabajo estime más conveniente), en diferentes contextos (multiples clientes, multiples versiones, etc).
A quienes quieran profundizar más les recomiendo la documentación que refiere al tema
Mi sensación sobre el tema es que el esquema de "versionado" quea permite GX Rocha en su Beta 2 sienta una base muy versátil que permite mantener "hilos de desarrollo" independientes, versiones diferentes por cliente, por ambiente, etc. Todo integrado en una misma KB lo que lo hace mucho más práctico y potente.
Está explicado en el wiki, de todos modos acá mi interpretación "sui generis" del asunto que pueda servir como "introducción" al tema.
Disclaimer: Aunque los conceptos son iguales para todo el mundo, este post está orientado especialmente para quienes vienen de versiones anteriores de GX ya que en ciertos momentos se hace un paralelismo entre los conceptos actuales y los de versiones anteriores.
Las bases
Cuando desarrollo una KB basicamente tengo dos cosas: objetos y environments
Los objetos son las transacciones, webpanels, dominios, atributos, documentos, etc.
Los environment refieren a las propiedades como base de datos utilizada, información de conexión a la misma, propiedades de ejecución, lenguaje, etc.
Diferentes environments
Suele suceder que una misma aplicación (grupo de objetos) requiere generarse para diferentes "environments", por mencionar ejemplos: diferentes DBMS, diferentes plataformas: en Java, .NET, Ruby o cualquier otra propiedad del estilo.
Eso en versiones anteriores de GeneXus se resolvía agregando un modelo porque era el único método para tener diferentes "sets" de valores de las propiedades. Así por ejemplo tenía un modelo .NET y otro Java o un modelo con SQL Server, otro con MySQL y otro con Oracle, etc.
En la Rocha, cuando se crea una KB, ya se establece un environment default y a su vez se pueden crear nuevos "environments", se puede ver el proceso en este video:
En todo momento tendré un "environment activo" que en definitiva es lo que gobierna para qué plataforma, DBMS, lenguaje, etc se está generando.
En este otro video se puede ver como activar (set target as) un environment:
Es decir, un modelo era un conjunto de objetos + un environment, eso en la Rocha no es más necesario y solo definiendo un nuevo "environment" es suficiente.Llamemos a esto (Objetos + uno o más environments) un "branch", digamos que una "linea de trabajo" dentro de la KB. Armin dabe un ejemplo de uso del tema en su blog.
Diferentes branches
Como comentaba antes, toda KB, ni bien se crea, tiene un "branch" inicial conocido como "trunk". No tiene nada de especial, solo que es el "tronco" de la KB y que su nombre es el propio nombre de la KB.
Se puede trabajar sobre ese branch y nada más o a su vez se pueden derivar diferentes "branches", es decir armar otro conjunto de "objetos+environments" que tienen un objetivo especifico.
Por ejemplo, en un momento se trabajará sobre un grupo de objetos a entregar en Marzo/2008 (llamémosle: corto plazo) y a la vez se está trabajando en una re-ingeniería de la KB que estará finalizada en Setiembre/2008 (llamémosle: mediano plazo).
Del mismo que hay una perspectiva "evolutiva", puede haber una perspectiva "por cliente" o por el motivo que sea que requiera tener más de un branch (linea de trabajo) sobre la misma KB.
Dentro de una KB siempre se está trabajando sobre un "branch" activo, digamos que en el ejemplo estaré trabajando sobre el "branch corto plazo" o el "branch largo plazo", que en definitiva es un conjunto de objetos en un "estado A" y que tiene asociado un conjunto de "environments" (set de valores de propiedades).
En este video se muestra como crear y activar branches:
Diferentes versiones
De un branch, además de otro branch, se puede derivar una versión.
Creo que la manera más fácil de entender una versión es: una "foto" del branch (objetos + environments) del cual se deriva. Es decir, quedan los objetos en un "estado A", y todos los environments en "estado A". Todo read-only. Similar a un backup.
Volviendo al ejemplo, habiamos derivado el branch "Corto plazo" que tenemos que entregar en Marzo/2008, entonces el 6/Dic/07 decidimos liberar la "Beta 2" de nuestra aplicación. Lo que hago es "activar" ese branch "Corto plazo" y derivar de él una versión, llamémosle "Beta2". Lo mismo podría hacer si fuera a hacer una entrega a un cliente, derivar una versión significa "congelar" lo que entrego al cliente.
En este video se puede ver como crear una versión a partir de un branch:
Mis usuarios testearán dicha versión y seguramente reportarán problemas, entonces podré corregirlos en el branch "corto plazo" y en algún momento derivar la version "beta 2.1".
Sin embargo si he realizado modificaciones en el branch "Corto plazo" que no quiero incluirlas en este momento, puedo derivar un nuevo branch de la versión "Beta 2" y realizar las modificaciones en el mismo.
En el siguiente video se muestra como derivar una versión de un branch:
Mientras los usuarios prueban la Beta 2, a su vez se continua trabajando en el largo plazo donde hago cambios más sustanciales.
En definitiva, con los "branches" y "versiones" puedo tener varias lineas de trabajo a la vez sobre la misma KB y en cada momento decidir con que branch trabajar. En el ejemplo está con una perspectiva "evolutiva" pero las necesidades pueden variar de acuerdo a las circunstancias de cada equipo, eventualmente preciso "branches/versiones" por cliente o por el motivo que fuera.
Resumen
Volviendo a lo del principio, el esquema de "objetos", "environments" (configuraciones), "branches" (objetos + configuraciones que representan una linea de trabajo) y "versiones" (objetos + configuraciones que representan una foto), sienta las bases para trabajar con diferentes metodologías (más o menos ágiles, más o menos flexibles, lo que cada grupo de trabajo estime más conveniente), en diferentes contextos (multiples clientes, multiples versiones, etc).
A quienes quieran profundizar más les recomiendo la documentación que refiere al tema
Comentarios
Publicar un comentario