Branching como apoyo a la configuración

Una de las ventajas de los sistemas de control de versiones es la posibilidad de mantener distintas líneas de código abiertas (branches o ramas). La acción de derivar código de una línea a otra es lo que en diveka (y en medio mundo) denominamos branching. Generalmente, cada línea tiene una política de desarrollo distinta, que establece que tipos de cambios se realizan sobre el producto. Utilizando esta breve definición, ya podemos sacar dos ventajas:

• Es posible configurar un mismo producto para diferentes necesidades, manteniendo una base común entre los dos. Esto se aplica, por ejemplo, a clientes distintos, plataformas distintas, etc.
• Es posible reflejar el estado del producto en un determinado momento, de forma precisa. Esto se aplica, por ejemplo, para distinguir versiones de desarrollo de versiones release de un mismo producto.

Podeis encontrar una buena tipología de branching en el siguiente artículo: SCM Branching Models (PDF), aunque obviamente es posible otro tipo de configuraciones en función del producto.

Así pues, introducidos en el tema, hoy me gustaría exponer el modelo de branching que utilizamos en Empresa Solidaria, y como este modelo flexibiliza nuestra producción.

En el repositorio de Empresa Solidaria existe una línea principal, a la que llamamos cariñosamente Main, donde se introducen nuevas características. La política de versiones que hemos trazado, establece que se libera una versión por mes y una serie de releases internas durante ese mes.

Por lo tanto, disponemos de líneas de versión sobre la rama de release de la Conselleria de Bienestar Social, que nos permiten configurar el producto para la Conselleria e ir integrando en esta rama todos los cambios que vayamos incorporando al producto. Es más, como trabajamos con secciones atómicas de código, en alguna ocasión hemos tenido que liberar cambios pertenecientes a una versión de release y tirar atrás algunos de ellos (en ese momento es en el que puedo justificar el coste de desarrollo del sistema de build :) ).

Para aquellas características que han sido ya implementadas, el equipo de QA puede dedicarse a testearlas en la correspondiente rama de QA. Una vez se completa, y se determina que el producto es suficientemente estable, se pasa a la rama de release. De igual forma, en el proceso de build se recoge código de otros componentes de desarrollo propio de diveka, que obviamente se utilizan en diversos productos. Cada componente, incorpora la información de cómo debe construirse, y el sistema de build es capaz de indicar qué tipo de configuración es necesaria para ese componente en el producto actual.

Afortunadamente, el sistema de build es capaz de generar una versión (y cuando decimos versión, es una release en toda regla, con instalador, documentación, pruebas unitarias, etc.) de forma automática, a partir de cualquier rama del producto, ya que estas están configuradas para contener la información de generación. ¿Quién dijo que era una pérdida de tiempo dedicarse a esto?

posted by Luis Belloch at 12:21 | permalink