Introducción gxservergxmx flor

Notas del editor

• #3: Workspace es donde los desarrolladores editan código (objetos), arman los componentes en que están trabajando, y prueban y hacen debug de lo que arman. No se trabaja todos juntos metiendo mano en un mismo “local”, sino que cada uno trabaja en su “garage”, 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.
• #4: GXserver utiliza precisamente este esquema, separando la KB que está alojada en GXserver, en la que se junta el trabajo de todos, de aquellas simples copias de trabajo que puede tener cada desarrollador para poder introducir cambios. 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. Lo primero que hay que hacer es…
• #7: En GX aparece una ventana como esta. Ahí pueden ver una lista de los objetos que GX sabe que tienen modificados localmente. Incluso pueden pedirle que les muestre una comparación para saber exactamente qué es lo que modificaron. 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. El primero es el que ya teníamos en la Evolution 1,
• #8: que es el modelo basado en “merge”. Esto significa que 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” automático de los cambios de uno y otro desarrollador. En Gxserver desde la primera versión contábamos con este modelo de integración, que es el preferido por la industria de software en general para los sistemas de control de versiones. Sin embargo, pueden existir proyectos u organizaciones específicos 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 Clashmaker (http://www.flickr.com/photos/clashmaker/) 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
• #9: 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 usuario libere el “lock” o haga “commit”. 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.
• #10: Estos son algunos consejos específicos relacionados con los workspaces. No compartir las KBs de desarrollo. Cada desarrollador debe trabajar con su propia copia, que conoce y controla, de forma de tener toda la autonomía necesaria para trabajar sin interferir a los demás, ni verse interferido por ellos Desarrollar siempre en KBs de desarrollo conectadas a una KB en GXserver. Aunque se trate de un solo desarrollador, la diferencia entre trabajar directamente en una KB, y trabajar con un repositorio es muy grande. El repositorio permite llevar en forma ordenada y documentada la evolución del proyecto, mientras que la copia de trabajo permite desarrollar con total libertad para hacer cambios y experimentar, con la tranquilidad de que se trata de un ambiente temporal. Es como trabajar en borrador y luego pasar en limpio. Mantenerse sincronizado. Si bien el tener copias de trabajo da la gran ventaja de la autonomía, es importante tratar de sincronizarse frecuentemente, de forma de que los cambios que se hacen puedan ser aprovechados y probados por los demás, y viceversa. Los eventuales problemas de integración que pudieran surgir, cuanto antes se detecten mejor.
• #11: 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, par cada uno de esos objetos, puedo pedirle que…
• #12: En un proyecto de software debemos llevar un registro completo de todos los cambios que ocurren. Por qué? Hay muchísimos escenarios 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 roto 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…
• #13: me muestre las diferencias que se introdujeron en ese commit, para lo cual se utiliza un…
• #14: 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 en uno de los escenarios estábamos buscando un error que introdujimos en los últimos días? Pues bien, si lo identificamos, podemos pedirle a GX…
• #15: que deshaga en nuestra KB los cambios que se habían hecho en ese commit!
• #16: Los cambios que están relacionados deben estar agrupados en un mismo commit. Eso facilita su mejor comprensión a la hora de probar/revisar esos cambios, o de analizar la historia pasada. Además, cuando esos cambios deben pasarse a otra rama de desarrollo, el tenerlos agrupados facilita estas operaciones. Por las mismas razones, los cambios que corresponden a diferentes temas deben hacerse en diferentes commits, cada uno con su correspondiente comentario. Si se utiliza un sistema de incidentes (tickets, o bug tracking), lo ideal es que cada commit corresponda a un único incidente y se pueden guardar referencias cruzadas entre cada commit y el incidente relacionado. Los comentarios en el commit son muy importantes. Incluso el más escueto comentario ayuda a distinguir unos commits de otros cuando se está revisando la historia. Algunas de las cosas que vale la pena destacar en un commit son: Para qué se hace el cambio (si corrige un error, cuál; si implementa algo nuevo, qué). Si hay un sistema de incidentes, puede alcanzar con el nombre y el número del incidente. Si hay algo relevante de por qué se hizo el cambio de cierta forma, conviene explicarlo. Si hay alguna forma alternativa que se descartó, conviene aclarar por qué (puede evitar que otros lo hagan en el futuro por no conocer esas razones).
• #17: 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…
• #18: Hacer backups con la frecuencia adecuada. Naturalmente debe haber un balance entre el volumen de almacenamiento y el riesgo que estamos dispuestos a correr. Hacer un backup a cada hora es muy seguro (lo máximo que puedo llegar a perder es lo de la última hora) pero obviamente es demasiado procesamiento y demasiado volumen de información. En el otro extremo, hacer un backup por año es demasiado riesgoso. Dependiendo de la naturaleza del proyecto (tamaño, frecuencia de cambios, criticidad, etc.), pueden agendarse backups diarios, semanales, o mensuales. De nada nos sirven los respaldos si no los mantenemos seguros. Esto que parece tan obvio es una falla frecuente: en muchos casos se guardan los respaldos en el mismo disco en el que están los originales. Como mínimo, los respaldos tienen que estar en otro disco. Preferentemente en otra máquina. Idealmente, en otro local. En casos extremos, en diferentes ciudades. Los procedimientos de restauración deben ser conocidos y probados. Por las mismas razones que se hacen los simulacros de incendio, es conveniente que cada tanto se haga la experiencia de restaurar la información a partir de un respaldo, porque es una buena forma de estar seguros de que estamos guardando todo lo que se necesita, y que tenemos las herramientas y el conocimiento necesario para restaurarlo cuando llegue el momento.
• #19: 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
• #20: Luego de haber liberado la versión 1.0, necesitamos trabajar por un lado en lo que será la versión 2.0, 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.
• #21: Todo aquello que se libere a los clientes o que se ponga en producción, debe tener un “congelado” correspondiente. Esto asegura que es posible volver a armar esa misma versión, que es posible inspeccionar cómo estaban los objetos cuando se armó esa versión (para entender cómo funcionaba algo, o por qué fallaba), y que es posible arrancar una línea de desarrollo a partir de ese estado. La foto debe sacarse en el mismo momento en que se libera o se pone en producción. Esto debe ser parte del propio proceso de liberación. Si lo dejamos para después, corremos el riesgo de que se introduzcan nuevos cambios y ya no sea posible congelar exactamente lo que se liberó. Las etiquetas que usamos para el congelado deben ser suficientemente descriptivas para saber qué representan, y para que lo encontremos cuándo sea necesario.
• #22: 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.
• #23: Desde GX además, se puede inspeccionar la historia de cualquiera de las versiones que están en el server, y más importante aún, si estamos viendo la historia de una versión que no es con la que estamos trabajando en esa KB…
• #24: El Trunk o línea principal, es la rama que siempre evoluciona. Es el destino final de casi todos los cambios (sean correcciones o nuevas features). El resto de las ramas derivan del Trunk, y los cambios que en ellas se hacen, son en su mayoría en algún momento propagadas al Trunk Para cada rama, debe estar claro cuál es la política a seguir. Por ejemplo, para una rama que es de “desarrollo”, debe estar claro que no se pueden armar para liberar a clientes o poner en producción. Por el contrario, para una rama que es de “release” y está en etapa de estabilización, los commits deben estar restringidos a correcciones de errores previamente aprobadas. Para una cierta política, siempre surgirán casos de duda o ambigüedad. Tener un referente o “dueño” de cada rama, permite centralizar las decisiones para estos casos, y asegurarnos de que sean coherentes.
• #25: 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. -- Imagen: published by Annette Davis (http://profiles.google.com/103036564694387407778) at http://picasaweb.google.com/lh/photo/ZW6JXyPE3VldlkNPD5NWAw
• #26: 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. Una de las herramientas más conocidas para estas tareas, de hecho incluso es la que utilizamos internamente en Artech, es un producto Open Source, llamado… -- 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
• #27: Cruise Control. Nosotros utilizamos la versión de Cruise Control implementada en .Net. Cruise Control 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. Cruise Control chequea periódicamente si hay nuevos commits en la versión que corresponda, en cuyo caso ejecuta un update sobre su propia copia de trabajo y dispara el proceso de armado. Permite ver el estado de cada uno de los proyectos configurados, reportes de errores, notificaciones de fallas, etc., etc. Todo en forma automática y totalmente desatendido. 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. El último componente en esta fórmula es el propio GXserver, ya que 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.
• #28: Los únicos componentes de un proceso de armado deben ser los fuentes, y las herramientas que los procesan. No valen procedimientos memorizados, ni escritos en papelitos. Versionar todas las dependencias. Si se utilizan componentes externos, también deben ser parte de lo que se guarda en el repositorio y se versiona Automatizar los procesos de build. Dados los fuentes y las herramientas, el armado debe poder realizarse en forma repetible y con un solo comando, sin que haya tareas manuales. Cualquier paso manual es una dependencia indeseada y un probable punto de falla.