GeneXus Server Evolution 2: desarrollo profesional, eficiente y bajo control
•Transferir como PPTX, PDF•
0 gostou•695 visualizações
Recomendados
Recomendados
Mais conteúdo relacionado
Mais de GeneXus
Mais de GeneXus (20)
GeneXus Server Evolution 2: desarrollo profesional, eficiente y bajo control
- 1. Desarrollo profesional, eficiente y bajo control José Lamas jlr@genexus.com @jlamasrios XXII Encuentro GeneXus 2 de Octubre de 2012
- 2. 1 - Use Separate Workspaces
- 4. Workspace Best Practices Don’t share workspaces 1 Don’t work outside of workspaces 2 Stay in sync 3
- 5. 2 - Keep track of changes
- 10. Changes Best Practices Group related changes 1 One commit per issue 2 Comment changes 3
- 11. 3 - Do Backup
- 13. Backup Best Practices Backup as often as needed 1 Keep backups safe 2 Have restore procedures 3
- 14. 4 - Record Milestones
- 16. Milestones Best Practices Freeze every release 1 Freeze at time of release 2 Use appropriate labels 3
- 17. 5 – Use branches
- 21. Branches Best Practices Have a Trunk 1 Give each branch a policy 2 Give each branch an owner 3
- 22. 6 - Make Builds Repeatable
- 23. MSBuild
- 24. Builds Best Practices Source + tools = product 1 Version every dependency 2 Automate builds 3
- 25. Development Best Practices Use separate workspaces Keep track of changes Do Backup Record Milestones Use branches Make builds repeatable
Notas do Editor
- 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 cáda 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 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…
- 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 ellosDesarrollar 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.
- 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…
- 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 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…
- que deshaga en nuestra KB los cambios que se habían hecho en ese commit!
- 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 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).
- 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 en GXserver, 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 todas su historia, con todos sus comentarios, todas las diferentes versiones, ramas de desarrollo, etc.
- 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 agendarsebackups 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.
- 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.
- 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.
- 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.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, diferentes 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.flickr.com/photos/cobalt/5581649735/sizes/o/in/photostream/
- 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…
- podemos pedirle a GX que nos integre en nuestra KB cualquier cambio que se haya hecho en aquella otra versión.En la versión Evolution 2, esta integración se hace con la misma tecnología de “merge” que mencionamos antes, de forma de aplicar automáticamente los cambios de una versión a otra, teniendo en cuenta que los objetos en una y otra versión pueden ser diferentes. De esta forma se evita que cambios hechos para la versión original “pasen por arriba” de otros cambios ya hechos en la versión de destino.
- 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 TrunkPara 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.
- 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: publishedby Annette Davis (http://profiles.google.com/103036564694387407778) at http://picasaweb.google.com/lh/photo/ZW6JXyPE3VldlkNPD5NWAw
- 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.
- 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 versionaAutomatizar 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.
- 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 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.Bibliografía:Branching and Merging Primer – Chris Birmele - http://msdn.microsoft.com/en-us/library/aa730834(VS.80).aspxSubversionBestPractices – SVN - http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.htmlHigh-Level Software Version Management BestPractices–Perforce - http://www.perforce.com/resources/white-papers/highlevel-software-version-management-best-practicesBestPracticesforVersion Control – AndersSandvig - http://blog.looplabel.net/2008/07/28/best-practices-for-version-control/Check In Early, Check In Often – Jeff Atwood - http://www.codinghorror.com/blog/2008/08/check-in-early-check-in-often.htmlPolicies / SVN CommitPolity – KDE - http://techbase.kde.org/Policies/SVN_Commit_Policy5 SVN bestpractices – Salvatore Iovene–http://www.iovene.com/21/Version Control Habits of EffectiveDevelopers – Brian St. Pierre - http://blog.bstpierre.org/version-control-habits