Técnicas Avanzadas de Control de Versiones

Ángel Armenta Martínezarmenta.angel@gmail.com@armenta_angel

Contenido

¿Qué vamos a ver hoy?

Repasaremos las buenas prácticas generales a la hora de usar el sistema de control de versiones.

Hablaremos del uso de las ramas y la conveniencia del uso de las mismas.

Perderemos el miedo a realizar merges. Veremos demos de lo expuesto.Podéis ver y descargar esta presentación en [link slideshare]

Subversion y TortoiseSVN ¿Por qué se ha elegido Subversion y

TortoiseSVN para esta presentación?

SVN es el software de control de versiones más usado en entornos empresariales.

Se supone por tanto que la mayoría de los asistentes lo usan, lo han usado o lo usarán.

TortoiseSVN es una de las herramientas visuales más potentes y maduras para operar contra el repositorio de SVN. Dispone de un sistema de merges muy avanzado.

De todos modos, prácticamente todo lo expuesto es extrapolable a cualquier otro sistema de control de versiones.

Buenas prácticas

Estructurar correctamente el repositorio (1/2)

Existen muchas maneras válidas de estructurar nuestro repositorio, pero oficialmente Subversion recomienda una raíz por proyecto/aplicación que contiene al menos los siguientes subdirectorios: /trunk, /branches y /tags:

Buenas prácticas

Estructurar correctamente el repositorio (2/2) Trunk: Aquí debe estar la versión actual y estable del proyecto. Es también llamada la rama de producción. Debe permanecer estable y complilable SIEMPRE.

Tags: Denotan puntos específicos en el historial de un proyecto (hitos), como por ejemplo entregas a producción. Son puntos de referencia y nunca debe trabajarse sobre ellos y modificar su contenido.

Branches: Se usa para trabajar en los cambios del proyecto paralelamente a la rama principal (trunk) evitando así romper la versión estable del proyecto.

Buenas prácticas

El repositorio de SVN no es un backup

• No pensar que SVN es nuestro sistema de backup. Procurar no realizar commits simplemente para “guardar el trabajo” por razones como “he terminado mi jornada laboral y voy a guardar”. Si lo necesitáramos, recurrir a otras opciones como por ejemplo Dropbox.

• Cuando hacemos commit, lo que debemos estar haciendo es generando una nueva versión estable, con nueva funcionalidad, etc.

Buenas prácticas

¿Cuándo hacer commit?

• No se debe hacer commit ni cada línea que se programe ni al final de la jornada.

• Se debe hacer un commit tan pronto como los cambios conformen una unidad lógica funcional, teniendo en cuenta que nunca deben romper la compilación.

• Estas unidades lógicas deberían acotarse para que los commits se vayan realizando de manera regular y no impliquen un lote muy grande de cambios en el repositorio, ya que de lo contrario podríamos encontrarnos con un escenario de conflictos con los desarrollos de otros miembros del equipo que podrían llegar a ser muy difíciles de resolver.

Buenas prácticas

Comentarios (1/2): precisos y exhaustivos

• Todo commit debe tener su comentario.

• El comentario debe ser preciso y exhaustivo. Se debe explicar correctamente lo que se ha realizado en el commit.

• Es buena práctica también marcar los commits de eventos como la creación de branches, tags y merges de manera estandarizada en el equipo. Por ejemplo, que el comentario de la apertura de un nuevo branch vaya precedido por la etiqueta [BRANCH]. Igualmente se puede estandarizar que el comentario indique la versión desde la que se abre la rama.

Buenas prácticas

Comentarios (2/2): ejemplos• [BRANCH] Nueva rama creada para el desarrollo de (evolutivo X,

corrección Y, etc.), a partir de la rama (Indicar rama), revisión (indicar número de revisión en SVN).

• [TAG] Versión instalada en producción el 20-10-2014 en el PaP de (la versión X.Y.Z, el evolutivo X, etc).

• [MERGE] Fusionamos las revisiones 9234, 9231, 9311-9412 de la rama branches/correctivos-v1.4.

Otras etiquetas pueden ser el código de incidencia del sistema de bug tracking, el código de proyecto, o combinaciones de estos:

[jira-1231], [HOME2013-5023], [EMP2014-3459/jira-86], etc.

Buenas prácticas

Ejecutando el commit (1/2)

1. Antes de subir nada, revisar si antes otra persona ha subido cambios al repositorio, realizando un update. Si existen cambios a descargar, pueden entrar en conflicto con los nuestros. En ese caso, debemos resolver esos conflictos antes de subir nuestros cambios.

2. Revisar los cambios a “commitear”, procurando no subir binarios, archivos innecesarios de configuración, etc. Puede ser necesario usar la función “add to ignorelist”.

3. Recuerda que el commit será atómico. Todos los cambios contenidos en el subirán, o no subirá nada. Es decir, un número de revisión contendrá cambios en uno o múltiples ficheros y/o en la estructura.

Buenas prácticas

Ejecutando el commit (2/2)

Buenas prácticas

Actualizarse la rama de trabajo a menudo

• Es conveniente actualizarse la rama de trabajo a menudo para incorporar en ella los cambios que otros miembros del equipo hayan realizado sobre la misma. De esta manera reduciremos las posibilidades de conflictos con otros commits a la hora de subir nuestros cambios, evitando la resolución de los mismos, la cual en ocasiones puede ser complicada.

• Si vamos a empezar a trabajar en una rama que habíamos descargado hace ya un tiempo, lo primero que debemos hacer es actualizarla.

• Por supuesto como ya hemos comentado, siempre antes de un commit.

Buenas prácticas

No subir ficheros innecesarios al repositorio• Los binarios resultado de compilar los fuentes, p.e. en Java los .class

• Los instalables finales fruto de la compilación de una librería, componente o directamente el proyecto completo, p.e. lib-accesobd-1.3.jar, facebook.war.

• Los archivos de log que genera nuestra aplicación cuando la hemos puesto en marcha en nuestro equipo mientras desarrollábamos o bien mientras lanzábamos los tests.

• En definitiva, cualquier archivo que genere automáticamente la compilación o puesta en marcha del proyecto.

Existen recomendaciones de no subir al repositorio ficheros de configuración del entorno de trabajo como los IDEs (p.e. en Eclipse el

.classpath, .project, etc.).Yo personalmente no tengo problema en ello, de hecho me parece beneficioso en equipos donde todos o varios de sus miembros usan

el mismo IDE.

Demo

Etiquetas (Tags)

Una etiqueta o tag no es más que una instantánea (snapshot) del proyecto en tomada en un momento concreto. Se pueden tomar en cualquier rama de trabajo.

Se crean exactamente igual que una rama, sin embargo, no deben utilizarse para realizar modificaciones, deben permanecer inalteradas.

Se recomienda almacenarlas bajo el directorio /tags del repositorio.

Normalmente se usan para marcar versiones entregadas en producción, p.e. “release-1.0”, aunque podemos marcar cualquier otra revisión de interés como p.e. organizar las versiones entregas para pruebas.

Ramas

Hay quien las evita Dificultad de gestión de las mismas y sobretodo pánico al

momento en el que hay que realizar el merge. Se puede incluso encontrar textos y manuales de autores que

explícitamente piden que se eviten.

Sin miedo Son la solución para mantener segura la rama de producción,

mientras desarrollamos nuevas funcionalidades, parches y evolutivos.

Las herramientas existentes a día de hoy para realizar merges son muy buenas y mejores que nosotros tratando de realizar los merges a mano. Facilitan la resolución de conflictos.

Aumentarán nuestra productividad y nos permitirán dar al cliente más opciones para realizar entregas del proyecto.

Ramas

Escenario básico (1/2)

El escenario más básico, es el de una rama de producción o Trunk desde la cual se abren otras ramas en las cuales s pueden estar desarrollando funcionalidades en paralelo (6, 7).

Los cambios de las ramas se van integrando en el Trunk (flechas verdes) cuando se alcancen hitos en el desarrollo que deban subir a producción.

Cuando tenemos ramas en paralelo, puede ser necesario que estás reciban cambios que se han llevado al Trunk (flecha verde 10-11)

En ocasiones querremos marcar con un tag hitos como una entrega real en producción o la referencia a una fusión de cambios (5, 13).

Aunque una rama haya llevado sus cambios al Trunk, podemos seguir avanzando sobre ella o bien discontinuarla sin más (15, 16).

Ramas

Escenario básico(2/2)

Una pequeña vuelta de tuerca a lo expuesto en la transparencia anterior.

Los puntos sobre las ramas representan commits (establecen una revisión en SVN). Las líneas negras en realidad representan un tag. No hay desarrollo sobre ellas.

Ramas en paralelo en las que las que se ha realizado una división de desarrollos por funcionalidades. A y B completan la R1 y cuando terminamos la C se completa la R2.

Vemos como tras aplicar cambios en la rama Main, estos son volcados sobre las ramas con desarrollos en curso.

Cierto es que la dificultad de gestionar correctamente las ramas crece exponencialmente en función de su número.

Ramas

Escenario avanzado (1/6)

Ramas

Escenario avanzado (2/6)

Principales ramas: Master (Trunk, Prod,…) Develop (prj-a, prj-b,…)

La rama Master recibe cambios de la(s) rama(s) Develop.

Estos cambios coinciden con la generación de una nueva release (p.e. 0.1, 0.2, …).

Ramas

Escenario avanzado (3/6)

Feature branches: Cuelgan de la rama develop. Se pueden abrir en paralelo varias

f.b. desde cualquier punto de la rama develop.

Los cambios de las f.b. se fusionaran en la rama develop cuando estén listos. La rama f.b. fusionada quedará obsoleta.

Es un caso atípico que las f.b. reciban cambios (merge) desde la rama develop. Sin embargo puede llegar a darse si fuese necesario incluirlos si afectase al desarrollo y/o pruebas de la f.b.

Ramas

Escenario avanzado (4/6)

Hotfixes branches: Si se descubre un bug

importante en la versión Master (versión de producción), se abrirá una rama de hotfixes para su corrección.

Una vez terminada la corrección, se aplicará en la rama Master.

Esta corrección también tendrá que ser llevada a la/s rama/s develop y de esta/s a sus f.b. si fuera conveniente.

Ramas

Escenario avanzado (5/6)

Release branches: El cumplimiento de ciertos hitos de

desarrollo en la rama develop puede conformar una nueva release.

La nueva release puede que no vaya a subir a producción todavía y que tenga que crearse una r.b.

Sobre dicha r.b. solo se corregirían bugs de la funcionalidad esperada en la release.

Los cambios en la r.b. se irían fusionando en la/s rama/s develop, nunca al contrario, ya que se supone que una r.b. contiene una serie de funcionalidades cerrada.

Ramas

Escenario avanzado (6/6). Resumen. La rama principal recibe los cambios realizados en las

otras. Estos se marcan con tags. En la rama hotfixes se solucionan incidencias en

producción. Pueden existir una o más ramas develop. Tantas como

proyectos en paralelo llevemos. Cuando convenga, se abrirán feature branches

colgando de la rama develop (aislar desarrollos, repartición del trabajo, …).

La finalización de ciertos hitos en la rama develop y sus f.b. conformarán una branch de release en cierto momento según acuerdos del proyecto (p.e. cierre de un sprint). Sobre esa rama solo se podrían corregir bugs. No avanzar en el proyecto, este continua en la rama develop y sus f.b.

Hay merges en los dos sentidos entre las ramas develop – release y develop-f.b.

Los errores corregidos en la rama hotfixes también serán fusionados en la/s rama/s develop a conveniencia.

Ramas

Buenas prácticas Borrar (o mover por ejemplo a /branches/outdated) las ramas

obsoletas (se han integrado sus cambios en la principal, han sido descartadas sus modificaciones, etc.). Es una cuestión de claridad.

Sigue la pista de tus ramas. Revisa el histórico, ten claro a partir de que rama y revisión se crearon (usa comentarios apropiados al crearlas), usa el gráfico de revisiones (Tortoise p.e. ofrece uno), etc.

Nómbralas correctamente en su creación. Usa prefijos: fix-, feature-, project-, e incluso mezclalos apropiadamente.

Divide bien las funcionalidades a implementar para que puedas realizar commits frecuentemente.

Los cambios fuertes en la estructura, si es posible, hacerlos en la rama principal en un momento en los que esta se haya quedado como única rama activa.

Demo

Merge

¿Hacemos un merge Wendy?

Merge

Las herramientas actuales (p.e. TortoiseSVN o muchos plugins que se integran en nuestros IDEs) realizan los merges de manera semiautomática, tan solo se pararán en los conflictos.

Muchos equipos no dan el paso de utilizar esas herramientas e integran los cambios a mano. ¡Eso si da miedo!. Los fallos humanos son los culpables del miedo actual a los merges.

Si aprendemos a manejar correctamente las herramientas (y es más sencillo de lo que parece), tan solo tendremos que preocuparnos de los conflictos.

La mayoría de merges se resuelven sin conflictos. A su vez la mayoría de los conflictos no suelen ser difíciles de

resolver. Solo unos pocos pueden dar dolor de cabeza, pero son una

oportunidad para tomar un café con tu compañero y resolverlo.

Perdiendo el miedo

Merge

Se descarga la rama sobre la que se van a incorporar los cambios en el equipo local. (Destino).

Se elige la rama de la cual se recogerán los cambios a incorporar. (Origen).

Se seleccionan las revisiones de la rama origen a incorporar sobre la rama destino (no tenemos por que fusionar todos los cambios que se hayan realizado en la rama origen).

Se realiza el merge. Los cambios quedan en la copia local y se pueden revisar antes de hacer commit de los mismos en el repositorio.

Los conflictos quedarán pendientes de resolver también en nuestra copia local. Podremos usar las herramientas de diff y merge visuales que nos ofrece TortoiseSVN por ejemplo.

Nuestro cliente de SVN no nos dejará realizar el commit de archivos con conflictos pendientes de resolver.

¿Cómo se realiza un merge?

Merge

Cuando un mismo archivo ha sido modificado en las ramas implicadas en el merge.

No siempre se da conflicto aunque se cumpla la premisa anterior. A menudo las herramientas son capaces de resolver y fusionar los cambios en un mismo archivo.

También existen los conflictos a nivel de estructura del proyecto (el árbol de directorios).

¿Cuándo se da un conflicto?

Demo

Merge

Planificación: Evitar en la medida de lo posible que las ramas que creemos conlleven a la resolución de conflictos en el merge. P.e. planificando las ramas de correción de bugs o de funcionalidades (f.b.) basándonos en su localización. También se puede repartir el trabajo del equipo asignando módulos separados del proyecto a cada miembro. Con ambas precauciones, reducimos las posibilidades de que los miembros del equipo trabajen en los mismos ficheros al mismo tiempo.

Actualizar la rama antes de comenzar a trabajar en ella: Siempre que empecemos a trabajar en una rama, asegurarse de haber descargado sus últimos cambios antes de comenzar nuestras modificaciones. De este modo evitamos merges innecesarios por no haber tenido la última versión de ese archivo que ahora da conflictos por una modificación anterior a cuando comenzamos a trabajar con el.

Seguir actualizándola frecuentemente: Actualiza la rama en la que estás trabajando de manera frecuente para ir recogiendo los cambios de los demás miembros del equipo. Por las mismas razones que el punto anterior.

Buenas prácticas: Evitando los conflictos

Merge

Realizar el merge cuando corresponda: Por ejemplo, esperar a haber completado correctamente la funcionalidad de una f.b.. No realizar el merge si todavía vamos a seguir trabajando en la f.b.

Comentar correctamente nuestros commits: Ayudarán a la hora de resolver conflictos.

Resolver los conflictos lo antes posible: Tan rápido como se resuelvan y suban los cambios al repositorio, el equipo podrá tomar referencia de ellos para seguir trabajando con normalidad sobre los archivos implicados.

Previsualiza el merge: Usa la opción Test Merge de tu cliente de SVN. Te ayudará a previsualizar el resultado del merge.

Segunda oportunidad: Si la resolución de un merge rompe la compilación, los tests o algo no está bien, revierte los cambios en local y vuelve a empezar, y es que los merges se resuelven dos pasos: primero en la copia local y segundo un commit que los sube al repositorio.

No entres en pánico: Los conflictos ocurren y frecuentemente son sencillos de resolver. Si alguno se complica, trátalo con los miembros del equipo que realizaron modificaciones en los archivos del conflicto.

Buenas prácticas: Más consejos

Fin

¿Preguntas?

Referencias

Apache Subversion https://subversion.apache.org/

TortoiseSVN http://tortoisesvn.net/

SVN Red Book http://svnbook.red-bean.com/

A Successful Git Branching Model http://nvie.com/posts/a-successful-git-branching-model/

Tutorial: Apache Subversion Best Practices http://jaxenter.com/tutorial-apache-subversion-best-practices-105502.html

Busy Developer’s Guide to Subversion Best Practices http://blogs.wandisco.com/2011/12/21/busy-developer%E2%80%99s-guide-to-subversion-best-practic

es/

Subversion Best Practices: Repository Structure http://blogs.wandisco.com/2011/10/24/subversion-best-practices-repository-structure/

Best Practices for Merging in Subversion http://blogs.wandisco.com/2011/11/08/best-practices-for-merging-in-subversion/

Feature Toggles vs Feature Branches – Dylan’s $0.02 http://geekswithblogs.net/Optikal/archive/2013/02/10/152069.aspx

Buenas Prácticas Subversion por Iker Canarias http://www.slideshare.net/ikercanarias/subversion-buenas-prcticas

Introducción a Subversion por Irontec http://www.slideshare.net/irontec/charla-svn-subversion-522278

Licencia

Este documento está protegido bajo la licencia: Atribucion-NoComercial-CompartirIgual 4.0 Internacional. http://creativecommons.org/licenses/by-nc-sa/4.0/

Compártelo o adáptalo reconociendo la autoría, sin fines comerciales y bajo la misma licencia.