Sin embargo, hay muchas razones por las cuales no sólo es razonable utilizar un repositorio de control de versiones aunque haya un solo desarrollador, sino que de hecho es la mejor opción para un trabajo profesional.
1 – VIAJAR AL PASADO
El registro histórico de cambios nos da toda la información sobre qué cambió, cuándo, y por qué. Por ejemplo, nos permite responder preguntas como: “¿Qué cambié en la última semana que puede haber producido este nuevo error?”.
Es verdad que si trabajamos sin GXserver, GeneXus también provee una historia de cambios por objeto, creando una revisión cada vez que el usuario lo salva. Pero la historia de los cambios en GXserver va mucho más allá de esto, porque cuando hacemos un commit, estamos definiendo un grupo lógico de objetos que cambian al mismo tiempo y con una intención específica y declarada (ie: comentarios del commit). Los comentarios incluso pueden tener una referencia a un número de ticket de un sistema de seguimiento de errores o de manejo de proyectos.
Cuando algo falla, tenemos todo lo necesario para revertir los errores. Muchas veces los cambios en un objeto están relacionados con cambios a otros objetos. Por ejemplo, si cambiamos los parámetros de un procedimiento, tendremos que cambiar también los objetos que lo llamaban. Tener el conocimiento de cuáles fueron todos los objetos modificados en cada commit, nos permite estar seguros de que estamos corrigiendo todos los objetos que lo necesitan.
De la misma forma, para entender por qué a un objeto le hicimos cierto cambio, es fundamental la información de contexto; es decir qué otros objetos cambiaron en ese mismo momento, e incluso cuál era el estado de los que no cambiaron.
2 – MEJOR MANEJO DE VERSIONES
Por supuesto que también podemos tener versiones congeladas y nuevas ramas de desarrollo en una KB incluso sin GXserver, pero usando GXserver obtenemos además la facilidad de publicar cualquiera de estas ramas a procesos externos o servidores de armado o integración continua, en forma desacoplada y sin las penalidades de performance asociadas a un acceso compartido por la red a una KB.
La KB en la que desarrollamos solo necesita tener la rama en la que estamos haciendo cambios, mientras que en el server podemos tener todas las versiones congeladas y todas las ramas de desarrollo. Un servidor de integración continua puede estar monitoreando los commits que hagamos en cualquiera de las versiones, para disparar un proceso de armado de la versión, ejecución de tests, deploy, etc.
3 – LIBRE EXPERIMENTACIÓN
En nuestra KB local, podemos experimentar y probar libremente, contando con la seguridad de que nada de esto afecta la versión “oficial” a menos que explícitamente hagamos commit de los cambios. Una vez que estamos listos para hacer un commit, podemos revisar el reporte de cambios pendientes de commit, comparar cada objeto con su estado original, y decidir cuáles incluir en el commit, cuáles fácilmente revertir a su estado inicial, y cuáles mantener como cambios locales.
GXserver controlará además que el conjunto de objetos incluido en el commit sea coherente (por ejemplo, que no incluyamos una llamada a un objeto nuevo que olvidamos incluir), y en caso de cualquier error rechazará todos los cambios sin modificar nada, de forma de asegurar que todo commit forme una unidad lógica de cambios completa y que nunca perdemos la integridad de la KB del server.
4 – RESPALDOS MÁS FÁCILES
Nunca es necesario hacer respaldo de múltiples copias de una misma KB, y siempre tenemos claro qué es exactamente lo que necesitamos respaldar: las KBs administradas por el server. En tanto hagamos commit y tengamos una adecuada política de respaldo de las KBs del server, estamos asegurados de posibles pérdidas de las KBs locales, sean debidas a fallas de discos, notebooks robados, o cualquier causa similar.
Si utilizamos el GXserver Online (suscripción a GXserver en la nube), incluso contamos con respaldos automáticos de todas las KBs.
5 – INSPECCIÓN ONLINE DE LA KB
GXserver provee una consola web por la cual podemos inspeccionar las KBs, el contenido de sus objetos, y la actividad de cambios. No es necesario contar con GX para esto, alcanza con un browser. Si tenemos nuestra instalación de GX y las KBs en la oficina, igual podemos usar esta consola desde casa o cuando estamos de viaje.
6 – INTEGRACIÓN DE OTROS ACTORES
Podemos dar acceso a la consola de GXserver para integrar a otras personas que aunque no desarrollan están involucradas en el proyecto y necesitan monitorear su desarrollo, como por ejemplo, un gerente, o un cliente para el cual estamos desarrollando el sistema.
Por otra parte, el desarrollo de un proyecto muchas veces requiere de la participación de varios otros actores que pueden utilizar la consola del server para tener acceso a la información de la KB, sin necesidad de que tengan efectivamente la KB ni tampoco una licencia de GX. Ejemplos de esto pueden ser los que trabajan en la documentación, traducciones, o el diseño gráfico.
7 – CUALQUIER MOMENTO, CUALQUIER LUGAR
Incluso si somos el único desarrollador, podemos obtener una copia actualizada del server desde cualquier lugar. Por ejemplo, podemos tener una KB local en la oficina y otra en casa, y sincronizarlas a través de GXserver sin esfuerzo.
En caso de que agreguemos un nuevo desarrollador, ya sea en forma permanente o temporaria, es sumamente fácil obtener su KB de trabajo, en el momento que sea, y esté donde esté.
EN RESUMEN
Usar una herramienta de manejo de versiones y la metodología asociada a esto, es una de esas cosas que a veces nos parece que no vamos a necesitar, hasta que comenzamos a usarlas. Luego nos damos cuenta de que las ventajas son muchísimas, y entonces nos parece mentira que antes pudiéramos trabajar sin ella.
Una de las ventajas más notorias es la facilidad con que podemos incorporar el trabajo de diferentes personas en un mismo proyecto, logrando que todas ellas trabajen en forma autónoma, sin interferencias, pero al mismo tiempo facilitando y organizando la integración del trabajo de todos.
Sin embargo, las ventajas de utilizar metodología y herramientas de control de versiones son tantas, aun para un solo desarrollador, que resulta indispensable para un desarrollo de software profesional. Las de arriba son solo algunas de las ventajas más salientes, pero sin duda que puede haber muchas más.
De hecho, esto no es específico de GeneXus o GXserver; aplica igualmente para cualquier desarrollo de software con lenguajes tradicionales, y siempre que surge la pregunta, la recomendación es la misma: conviene utilizar control de versiones aunque haya un solo desarrollador.?
*Publicado originalmente en el
Blog de José Lamas