Introduccion a GXserver
•Descargar como PPT, PDF•
0 recomendaciones•794 vistas
Introduccion a GXserver
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Más de GeneXus
Más de GeneXus (20)
Introduccion a GXserver
- 2. #GX23 1 – Use Separate Workspaces
- 3. #GX3140
- 4. #GX3140 Send KB to Server New KB from Server
- 6. #GX3140
- 7. Merge model
- 9. #GX23 2 – Keep track of changes
- 10. #GX23
- 14. #GX3140 3 – Do Backup
- 16. #GX3140 4 - Record Milestones 4 – Record Milestones
- 18. #GX3140 5 – Use Branches
- 20. #GX3140 6 – Automatic Builds
- 22. #GX23 TEMAS Separate Workspaces Do Backup Use branches Keep track of changes Record milestones Automatic Builds SUMMARY
- 24. #GX23 DESTACADOS Más información y mejor UX en la nueva consola de Gxserver Oscar Fabricio Lunes 30 – 15.30hs. – Ballroom C Metodología de trabajo en equipo: Gxserver Douglas de Oliveira Lunes 30 – 15hs – Ballroom Other activities
Notas del editor
- La idea de esta charla es comentarles acerca de GeneXus Server, sus características, la utilidad que puede tener en sus organizaciones y distintos escenarios en que tiene sentido su uso. ¿Qué es GeneXus Server? Bueno, es un producto, pero lo es en un doble sentido. Es en primera instancia un producto en la acepción de producto de software, de herramienta informática que resuelve un problema. Pero también lo es en el sentido de fruto de un proceso, en este caso un proceso en el cual quisimos plasmar las mejores prácticas en el desarrollo de software y toda la experiencia del equipo de desarrollo de GeneXus y con GeneXus. Estamos muy satisfechos con el resultado y creemos firmemente que GeneXus Server es la herramienta para el desarrollo en equipo con GeneXus. Vamos entonces a ir analizando distintos escenarios en que GeneXus Server puede aportar a una buena gestión de un proyecto. Empecemos con el escenario del trabajo en equipo…
- El desarrollo de software no es una actividad individual. Aún en casos de un solo desarrollador es una actividad colectiva en la que intervienen analistas, diseñadores, usuarios que validan la aplicación y muchos otros actores, dependiendo de la complejidad del proyecto. Ni que hablar cuando tenemos un equipo de desarrollo con diferentes roles: gerente de proyecto, jefe de desarrollo, desarrolladores, área de testing o distribuidos geográficamente… Pero siendo como es una actividad grupal, le viene como anillo al dedo aquella máxima de ‘juntos pero no entreverados’. Si bien el resultado final es fruto de un trabajo colaborativo, hay una etapa en la que el desarrollo es una actividad esencialmente individual, llevada adelante dentro de un plan general. Los desarrolladores editan código (objetos), arman los componentes en que están trabajando, y prueban y hacen debug de lo que arman en un ambiente propio. No se trabaja todos juntos metiendo mano en un mismo “local”, sino que cada uno trabaja en su “laboratorio”, con autonomía de lo que están haciendo los demás, y se utilizan luego mecanismos por los cuales cada desarrollador publica cambios y recibe los de los demás.
- GXserver utiliza precisamente este esquema, separando la KB que está alojada en GXserver, en la que se consolida el trabajo de todos, de aquellas simples copias de trabajo que puede tener cada desarrollador. Les presento a Peter y a Violeta que son miembros de un equipo que nos va a estar ayudando en varias cosas durante este Encuentro. Ellos son dos desarrolladores de software y forman parte de un equipo responsable del desarrollo y mantenimiento de una aplicación hecha con GeneXus. Nosotros, por economía del lenguaje, generalmente hablamos de la KB, en singular, pero en la realidad hay múltiples KBs para un mismo sistema. Lo que GeneXus Server propone es que hay una, que es la que está arriba, que es la relevante, en tanto es la que contiene todos los objetos que han sido liberados por los distintos desarrolladores y luego hay copias de trabajo, probablemente una por cada desarrollador, en la que éstos van implementando las funcionalidades que caen bajo su responsabilidad. Esta separación existe incluso aunque se trate de un solo desarrollador. Por un lado está la KB alojada en el server, que contiene toda la historia, las versiones, y el estado actual del proyecto, y por otro lado está la copia que se usa para desarrollar, en la cual se experimenta libremente, se va hacia atrás y hacia adelante, se prueba, etc.. Los cambios que se incorporan a la versión del server se pasan en una operación explícita, controlada, que agrupa todos los cambios relacionados a cierta funcionalidad o corrección. Algunos de los cambios que se hacen en la KB del desarrollador, terminan siendo descartados y nunca llegan a pasarse a la KB del server. Una vez definida esta separación, todo funciona con un protocolo de trabajo muy simple, utilizando solamente 4 operaciones básicas, integradas en el IDE de GX. El proceso comienza como siempre, con un desarrollador que crea una KB. Supongamos en este caso que es Peter. En su instalación local de GeneXus crea una nueva KB, define algunos objetos y a partir de allí lo primero que hay que hacer es…
- publicar esa versión inicial de la KB en GXserver. Sea una KB que ya existe, o que se acaba de crear, se puede publicar en GXserver con una opción del menú de GX llamada “Send Knowledge Base to Server”. Una vez publicada la KB, cualquier otro desarrollador puede obtener su propia copia de trabajo, utilizando en GX la opción “New – Knowledge Base from Server”. De este modo se genera para cada desarrollador un ambiente de trabajo independiente, que no afecta lo que estén haciendo los demás miembros del equipo y en el cual tiene absoluta libertad para experimentar y ensayar diferentes soluciones para implementar una funcionalidad. Tanto la KB original utilizada para hacer el “Send”, como las obtenidas posteriormente desde el server, se consideran conectadas a la KB del server, y por lo tanto disponen de otras 2 operaciones:
- Cuando uno de los desarrolladores considera que una funcionalidad, el arreglo de un bug o lo que sea está en condiciones de ser liberado, realiza la operación de “Commit” que le permite enviar cambios al server. Eso lo va a hacer desde su KB local. GeneXus le informa todos los objetos que están pendientes de hacer Commit y Peter podrá decidir si los envía todos o si sube solamente un subconjunto de ellos al Server. GeneXus se encarga de conectarse con GeneXus Server y enviarle los cambios. GeneXus Server los recibe y los incorpora en su Base de Conocimientos: la consolidada.
- En GX aparece una ventana como esta. Ahí el desarrollador puede ver una lista de los objetos que GX sabe que han sido modificados localmente. Incluso pueden pedirle que les muestre una comparación para saber exactamente qué es lo modificado. Pueden seleccionar qué objetos quieren que sean parte del commit, cuáles no, e incluso con una opción “Revert” del menú contextual deshacer los cambios de algún otro. Luego de seleccionar el conjunto de objetos, se escribe un comentario descriptivo de los cambios incluidos en ese commit, y se mandan al server. Después de hacer el commit, los demás usuarios pueden obtener esos cambios con la operación de Update, para la cual GX también permite ver la lista de los objetos que se van a actualizar, hacer comparaciones para saber qué cambios trae, y seleccionar todos o solo algunos de los objetos para que se actualicen. Para este esquema de trabajo, existen a su vez dos variantes, dos modelos de integración de cambios: se puede utilizar tanto el modelo de Merge, como el modelo basado en Locks.
- El modelo basado en “merge” es el más optimista en el sentido de considerar que el conflicto entre desarrolladores va a ser la excepción. Por lo tanto en esta forma de trabajo no es necesario hacer “lock” de objetos sino que cada desarrollador trabaja en forma autónoma en su KB y hace commits y updates. En los casos en que un mismo objeto es modificado por más de un usuario, la gran mayoría de las veces GX y GXserver resuelven de forma automática la integración, haciendo “merge” de los cambios de ambos desarrolladores. Volviendo al ejemplo en que Peter hacía un ‘commit’, en ese momento hay objetos en el Server que son diferentes de los que Violeta tiene en su KB local. Ella podrá, cuando lo entienda conveniente, sincronizar su KB local con la del Servidor y eso lo realiza mediante la operación de “Update”. Ese ciclo en el cual todos los desarrolladores van aportando a la KB consolidada y van recibiendo desde ella los cambios introducidos por el resto del equipo es el ciclo de trabajo normal. Pongamos el foco un momento en la operación de Update. Cuando Violeta trae los objetos que Peter envió al Server mediante el commit, pueden darse dos situaciones: que Violeta no hubiese modificado ninguno de ellos o que sí hubiese realizado cambios en alguno. En el primer caso no hay problema. Supongamos que Peter modificó la Transacción de Clientes y Violeta no había hecho ningún cambio en su KB local en ese objeto. En ese caso no hay ningún conflicto y GeneXus realizará la copia en la KB local de Violeta de la versión que Peter subió al Server. Veamos ahora el caso en que Violeta sí había hecho una modificación en la transacción Cliente. También aquí podemos tener dos situaciones. Veamos primero el caso en que Peter modificó por ejemplo la estructura y Violeta modificó las reglas de la transacción. En ese caso tampoco hay problema. GeneXus tiene la inteligencia para hacer un merge, es decir la fusión de las dos versiones y entonces en la KB de Mary quedan los cambios que hizo Peter más lo que había hecho Violeta y aún no subió al Server. Es decir que los cambios que hizo Peter tienen un commit hecho y los que hizo Violeta están pendientes de hacer commit en su KB. Supongamos ahora que los dos cambiaron la estructura. Peter agregó un atributo y Violeta modificó o eliminó otro. Ese caso también GeneXus lo resuelve automáticamente haciendo el merge entre ambas versiones. Lo mismo pasa con las reglas. La inmensa mayoría de los casos se resuelven de esta forma. Sin embargo hay un pequeño porcentaje que no queda contemplado en esta lógica. Es la situación en que los dos modificaron la misma regla por ejemplo. En ese caso no hay forma de saber cuál de las dos versiones debe prevalecer. Lo que hace entonces GeneXus es optar por lo más probable y permitir la marcha atrás. ¿Qué es lo más probable? Que la versión correcta sea la que está en el Server, porque si alguien hizo un commit eso tiene muchas más chances de reflejar el comportamiento deseado que algo que es un cambio local. Pero como GeneXus va guardando todas las versiones de los objetos, avisa al desarrollador de esa situación y éste podrá optar por aceptar el cambio, quedarse con su versión local o integrar manualmente sus cambios a la versión del Server. Noten que en todo momento dije que GeneXus resuelve los eventuales conflictos y no que lo hace GeneXus Server. Esto es porque todo este proceso los desarrolladores lo realizan desde el IDE de GeneXus y no desde la consola de GeneXus Server. En GeneXus Server desde la primera versión contábamos con este modelo de integración, que es el preferido actualmente por la industria de software en general para los sistemas de control de versiones. Sin embargo, pueden existir proyectos específicos o políticas organizacionales para los cuales se quiera utilizar un modelo alternativo, que está disponible a partir de la versión Evolution 2, que es Imagen: published by Andrew Euell ( http://www.flickr.com/photos/andyzweb/ ) bajo licencia Creative Commons Attribution-Share Alike 2.0 Generic (http://creativecommons.org/licenses/by-sa/2.0/deed.en). Ver http://en.wikipedia.org/wiki/File:Highway_401.png
- el modelo basado en locks. En este modelo, GX mantiene como “read-only” todos los objetos de la copia local, a menos que previamente se solicite y obtenga un “lock” (es una opción del menú contextual). Naturalmente GXserver solo da el “lock” sobre un objeto si no se lo ha dado previamente a otro usuario; en caso contrario es necesario esperar a que ese otro desarrollador libere el “lock” o haga “commit”. Obviamente con esta forma de trabajo no hay conflictos ya que nunca dos desarrolladores pueden trabajar sobre un mismo objeto. Este modelo de trabajo no es el que recomendamos utilizar en general, pero si por alguna razón particular desean utilizarlo, también está disponible. Hasta aquí lo relacionado con el primer escenario, el de resolver la integración del trabajo de varios desarrolladores en un mismo proyecto. Pasemos ahora a ver otros escenarios en los que GXserver también nos puede ayudar mucho. El segundo escenario…
- está relacionado con mirar hacia atrás y ver la historia de cambios del proyecto. En un proyecto de software debemos llevar un registro completo de todos los cambios que ocurren. ¿Por qué? Hay muchísimas situaciones en que el analizar la historia de cambios nos será de gran utilidad. Un primer caso de uso es la necesidad de revisar periódicamente (por ejemplo, todos los días) los últimos cambios, como para tener una idea del progreso del proyecto. Esto puede quererlo hacer un cliente para quién desarrollamos el proyecto, o un gerente que supervisa el desarrollo, o cualquiera de los desarrolladores para estar al tanto de lo que hacen sus compañeros. Un segundo escenario es que vuelvo de unas vacaciones. Como no pude participar de muchas reuniones, ni leí mensajes que pudo haber intercambiado el equipo, quiero obtener rápidamente una vista de qué fue lo que se hizo en mi ausencia. Otro caso frecuente es aquél en que descubro un error en el sistema que estamos desarrollando, pero sé que ese error no se producía con la versión de hace dos días atrás. En ese caso quiero poder responder la pregunta “¿que cambiamos en estos últimos dos días que pueda haber introducido un error en el sistema?” Entender cómo está desarrollado alguna parte del sistema no siempre es fácil cuando se trata de proyectos con mucho tiempo de evolución. El registro histórico nos brinda información de cómo evolucionó cada objeto desde años atrás hasta ahora, qué cambios específicos se hicieron en cada momento, quién los hizo, para qué los hizo, etc. Además, tener la información de cómo estaban otros objetos en el momento de cada cambio, y qué otros cambios se hicieron en ellos, es una información sumamente valiosa. En cualquiera de esos escenarios lo que quiero es obtener la historia de cambios. GXserver permite ver esta historia en la consola del server, y también desde…
- el propio IDE de GX. Ahí tengo una lista de los commits realizados, con su autor, fecha, y una lista de los objetos modificados en cada commit. Además, para cada uno de esos objetos, puedo pedirle que…
- me muestre las diferencias que se introdujeron en ese commit, para lo cual se utiliza un…
- comparador que resalta las partes modificadas, y dentro de ellas, qué cambios en particular se hicieron. En el ejemplo que se ve aquí, se distingue claramente que se quitaron 2 atributos de la estructura. ¿Recuerdan que una de las situaciones que mencionábamos era buscar un error introducido en los últimos días? Pues bien, si lo identificamos, podemos pedirle a GX…
- que deshaga en nuestra KB los cambios que se habían hecho en ese commit! Veamos ahora otro escenario bastante típico en todo proyecto de desarrollo:
- Debemos tener “backups” de lo que estamos desarrollando. Todos coincidimos en eso, pero no siempre se hace. A veces se vuelve complejo: “ Dónde está la KB que tiene los últimos cambios?” “ Con que KB se armó lo que se movió a Producción?” “ Dónde está la KB con la que armamos la versión de este cliente?” Como vimos al principio…
- Un aspecto fundamental de trabajar con GXserver es separar la KB que se usa como repositorio, de todas aquellas que pueden utilizarse como copias de trabajo. Teniendo esta separación, es muy claro que solo hace falta respaldar lo que está en el server, y para ello alcanza con un simple backup de SQL. Incluso es muy simple agendar la creación de backups, sean completos o incrementales, de forma que se realicen con la frecuencia deseada sin depender de nuestra intervención. Cada backup que hacemos de la KB del server está guardando no solo el estado actual del proyecto, sino también toda su historia, con todos sus comentarios, todas las diferentes versiones, ramas de desarrollo, etc. Muy relacionado con el escenario de los respaldos, está el siguiente escenario…
- Que es aquél por el cual necesitamos “congelar” ciertos momentos de la KB. Así como en nuestra vida a veces sacamos fotos que nos permitan recordar ciertos momentos, así en un proyecto de desarrollo hay momentos en que queremos sacar una “foto” de la KB, para estar seguros de que podemos volver a ella en caso de que sea necesario. Por ejemplo, esto sucede cada vez que liberamos una versión de nuestro producto, o cada vez que sabemos que estamos por introducir grandes cambios (potencialmente peligrosos) y queremos asegurarnos de poder volver rápidamente a ese estado sin tener que deshacer cambios de a uno. Para estos casos, trabajando con GXserver
- alcanza con indicar que uno quiere “congelar” y éste se encargará de hacer una copia completa del momento actual. Aún más, al crear copias de trabajo, es posible elegir una de estas versiones congeladas, con lo cual se puede reconstruir el estado de la KB en cualquiera de esos momentos. Todas estas fotos (versiones congeladas) están dentro de la misma KB del server, de manera que cuando hacemos backup de ella, estamos haciendo backup de todo a la vez. Las versiones congeladas, son también muy importantes para el siguiente escenario que vamos a analizar…
- que refiere a la necesidad de tener ramas de desarrollo paralelas. El poder tener múltiples líneas de desarrollo dentro de un mismo proyecto (generalmente conocidas como “Code-lines” o “branches”) es una de las mayores ventajas que ofrecen los sistemas de control de versiones, y sin embargo son muchas veces desaprovechados. Así como en la murga uruguaya, a partir de una raíz común cada integrante ‘evoluciona’ y tienen vestimenta y movimientos propios, pasa en la industria del software que los sistemas evolucionan en múltiples ramas y terminan creando soluciones que no tiene mucho que ver. El uso de branches permite gestionar de manera ordenada y controlada, las diferentes variantes que puede tener un proyecto, de forma tal que se comparta lo que es común, sin afectar la posibilidad de diferir en lo que sea necesario. Hay varias razones o situaciones por las cuales podemos necesitar abrir ramas de desarrollo separadas. Algunas de ellas son: Por versiones. Por ejemplo, en una rama se hacen arreglos sobre la versión 1.0 liberada (con vistas a la liberación de una versión 1.1), mientras que en la rama principal se hacen además cambios más grandes con vistas a la liberación de lo que será la versión 2.0. Por etapas de homologación. Por ejemplo, los desarrolladores no hacen commit directamente sobre la versión principal sino sobre una rama de desarrollo. Cada uno de esos commits, será testeado o revisado por alguien más, quien en caso de aprobarlo lo pasará a la rama principal. Por módulos. En un mismo proyecto, distintos equipos pueden trabajar cada uno sobre un módulo diferente, y hacer commit sobre ramas separadas. Periódicamente, los cambios en cada uno de los módulos son testeados y pasados a la rama principal. Por feature. Por ejemplo, si estoy por comenzar a desarrollar una nueva funcionalidad que sé que puede ser disruptiva, que me va a llevar cierto tiempo, y no quiero estar afectando al resto del equipo hasta que esta funcionalidad esté completada y estable, puedo desarrollar sobre una rama paralela, y hacer el pasaje a la rama principal cuando sea conveniente. Veamos por ejemplo el caso de branches por version: -- Imagen: http://www.morphisto.de/akademie/publikationen-und-poster/poster/
- Luego de haber liberado la versión 1.0, necesitamos trabajar por un lado en lo que será la versión 1.0.1, pero también – y por separado – en lo que será la versión 1.1 que será liberada mucho antes que la 2.0. Puede que incluso necesitemos estar trabajando en una versión 3.0 que liberaremos mucho más adelante. Otro caso en que esto es necesario es cuando tenemos un sistema en producción, pero que tiene actualizaciones periódicas. Como obviamente no podemos estar modificando directamente sobre el ambiente de producción, la solución es tener una versión de desarrollo sobre la que se va haciendo cambios, otra de test en la que se van pasando los cambios de desarrollo para probar, si los cambios son aprobados se pasan a una versión de pre-producción, y así hasta llegar a la versión de producción. Con GXserver esto se hace simplemente creando nuevas “versiones” a partir de cualquiera de las versiones que hemos congelado. Por ejemplo, una vez que congelamos la versión 1.0 que liberamos, podemos crear una versión de desarrollo a partir de ella, en la que iremos haciendo commit de los cambios para las actualizaciones a liberar de esta versión (1.1, 1.2, etc.). Mientras tanto, en la versión principal (Trunk) podremos estar haciendo commit de aquellas cosas que corresponden a nuestra próxima versión 2.0. Con lo que hemos estado viendo hasta ahora, queda claro que GXserver no solo nos permite tener bajo control y administrar todo lo relacionado con el desarrollo y la administración de nuestros proyectos, sino que también centraliza todo el conocimiento necesario para armar cualquier versión que nos interese, de entre las que tenemos en desarrollo o que hemos desarrollado en algún momento. En cualquier industria, cuando se tiene la posibilidad de almacenar y expresar el conocimiento necesario para armar algo, el siguiente paso suele ser…
- automatizarlo, lo que nos lleva al último escenario que les quería mostrar. Una vez que tenemos varias líneas de desarrollo, cada una de las cuales debe armarse desde diferentes KBs, quizá con diferentes versiones de GX, o diferentes configuraciones, que se mueven a diferentes lugares para que sean probadas o empaquetadas, etc., cómo mantener todo eso funcionando en una forma confiable y segura? Las cosas que ponemos en producción o que enviamos a nuestros clientes tienen que poder armarse nuevamente y con el mismo resultado a partir de lo que tenemos en el repositorio. No hay lugar para cosas que dependen de la memoria o de post-its en algún monitor. Cualquier paso manual, introduce una dependencia indeseada con quien realiza esos pasos (¿qué sucede cuando esa persona se enferma o se va de la compañía?), y una posibilidad de falla. Estas fallas además, probablemente ocurrirán en los momentos más críticos, cuando hacen más daño. Con GX y GXserver, se puede automatizar los builds, utilizando las tareas MSbuild. Algo que nos ha dado mucho resultado a nosotros con esto de hacer los builds repetibles es ir un paso más allá y no solamente automatizar el build, sino también automatizar el disparo de proceso de armado. En la industria de software esa automatización de los procesos de “Build”, está muy relacionada con lo que se conoce como… -- Imagen: published by Annette Davis (http://profiles.google.com/103036564694387407778) at http://picasaweb.google.com/lh/photo/ZW6JXyPE3VldlkNPD5NWAw
- Continuous Integration. Continuous Integration es una práctica en el desarrollo de software por la cual los desarrolladores (sea uno o varios) integran frecuentemente su trabajo (a través del commit a un repositorio) y de un proceso de build automático que permite detectar errores de integración tan pronto como sea posible. Cuando esto se da en el contexto de múltiples líneas de desarrollo, configuraciones, ambientes, etc., contar con este tipo de automatización es aún más relevante. Para hacer esto, internamente en Artech, utilizamos un producto Open Source, llamado Cruise Control, en particular la versión implementada en .Net. Cruise Control nos permite configurar el monitoreo de cada una de las versiones que se quiere armar, de qué línea de desarrollo, con qué versión de GX, dónde poner el resultado, etc., etc. El armado en sí, lo que Cruise Control dispara cuando necesita armar, son procesos MSBuild, utilizando las tareas que provee GX para especificación, generación, etc. Y además hemos implementado un plug-in para que Cruise Control reconozca GXserver como un repositorio más (la instalación estándar reconoce CVS, SVN, etc.), y pueda preguntarle por la existencia de nuevos commits, realizar updates, leer los detalles de cada commit para incluirlos en los reportes que emite, etc. Todo en forma automática y totalmente desatendido. En resumen… -- Imagen: fotografía de Abesam (http://commons.wikimedia.org/w/index.php?title=User:Abesam&action=edit&redlink=1) liberada al dominio público. Ver http://commons.wikimedia.org/wiki/File:Industrialbiotechnologyplant.jpg
- Hemos analizado aquí, seis escenarios o grupos de escenarios concretos en los cuales GXserver nos ayuda a tener bajo control nuestros proyectos de desarrollo. Sólo el primero de ellos estaba relacionado con equipos de trabajo, mientras que todos los restantes son fundamentales para cualquier proyecto profesional de software, independientemente del número de desarrolladores: registro histórico, respaldos, congelado, versiones paralelas, y automatización de build. Estas últimas son tan importantes que incluso para proyectos en que hay un solo desarrollador, es fundamental utilizar una herramienta como GXserver para poder contemplar todos estos aspectos que son vitales en un desarrollo hecho en forma profesional.
- GeneXus Server permite establecer un proceso de desarrollo profesional, en el cual los desarrolladores pueden concentrarse en las tareas de desarrollo, utilizando GXserver para la integración, administración y control de todo lo relacionado con la historia del proyecto, líneas de desarrollo, versiones, ambientes, y configuraciones. Además permite la estandarización, documentación y automatización de los procesos de armado, empaquetado, y deploy, para cada una de las posibles variantes que se derivan de cada proyecto.
- A quienes quieran seguir profundizando en este tema los invito a participar en estas actividades…