Patrones en Gestión de Configuraciones Software (VI y final)

Release-Prep Codeline

Este patrón trata de estabilizar un baseline para un release inminente, permitiendo paralelamente el desarrollo del proyecto sin afectar a tal release. Preparar un release implica pasar un buen número de pruebas, solucionar errores, preparar instaladores, documentación, etc. Si se realizan cambios importantes en este periodo crítico, pueden aparecer, de forma accidental, nuevos errores. Por otra parte, si congelamos el desarrollo por pulir el release, perdemos productividad.

Una posibilidad es crear una rama para tal release (al lector avispado que ha llegado hasta aquí leyendo los anteriores post seguramente ya se le había ocurrido tal solución antes de empezar a leer este párrafo), pero si bifurcamos demasiado pronto tal rama se pueden encontrar luego muchos errores en desarrollo que corregir en la release. Por consiguiente habrá que realizar muchas operaciones de fusión o merge, y tales operaciones sabemos bien que son complicadas. Aun así, es una buena solución, y es la que hemos ido adelantando en anteriores patrones.

¿Cómo solventar, entonces, los problemas de dicha solución? Crea la rama cuando el código se aproxime a la mayor estabilidad posible. De este modo el número de errores detectados (y consiguientes merges) será menor. Pero ojo: no esperes demasiado a crear tal rama de release o congelaras el desarrollo paralelo… en resumen: control, visibilidad máxima del progreso, y ojo al dato.

Task Branch

De este patrón podría hablar largo y tendido, y todo serían alabanzas; no en vano es el que usamos en la empresa donde trabajo y los resultados no pueden ser mejores: facilita el control de los cambios, la localización de dichos cambios y a qué afecta, facilita además la integración de dichos cambios en la rama principal, y favorece la productividad, junto con un software de control de tareas competente (Jira, OnTime, y en menor medida Bugzilla, Mantis…).

¿Cómo podría el equipo realizar múltiples cambios a largo plazo y que se solapan en una línea base sin comprometer la consistencia ni la integridad? No vale renunciar al uso de un control de versiones común, por descontado. El problema ya se propuso en otra ocasión: cómo controlar una tarea grande sin interferir en el trabajo de los demás.

La solución, una vez más: ramificar. Y es que el uso de ramas es tremendamente positivo, siempre que se usen con sentido, claro. Utiliza una rama diferente para cada actividad que represente cambios significativos en la línea base. Por tanto este patrón ya necesita un elevado soporte de políticas de desarrollo: definir tareas, asignar tareas, con un determinado tamaño, etc.

De este modo, disminuímos los riesgos (sus efectos, su probabilidad de ocurrencia). Una vez terminada tal tarea, la uniremos, junto con las demás, a la línea de desarrollo principal. Este merge deberá realizarse cuidadosamente para no romper nada que ya estuviera hecho (el lector ya debe estar pensando en otros patrones, como test unitarios, de smoke o de regresión…).

Este enfoque es muy útil cuando hay varias personas compartiendo un trabajo que debe integrarse en un todo. Por tanto, como hemos dicho, este patrón facilita la integración (si algún compañero lee esto se reíra de mí, pero tendrá que reconocer que si integrar es complejo y doloroso, sin este patrón sería una tarea bastante infernal…). Es importante integrar cada cierto tiempo cada rama (que representa a cada tarea) en la rama principal, sino la operación de fusión al final será muy trabajosa. Sin olvidar los riesgos que conlleva trabajar durante mucho tiempo con código desactualizado, lo cual ocurriría en ramas que se bifurcaron hace mucho y que han tardado mucho en integrarse. Solución: tareas cortas. ¿A alguien se le ha ocurrido ya que este patrón funciona de maravilla con metodologías ágiles, como Scrum?

Named Stable Bases

¿Con qué frecuencia integrar? Es importante estabilizar interfaces cuanto antes y que el resto de cambios, más frecuentes, tengan que ver con el cuerpo del código. Etiqueta claramente y de forma coherente aquellos puntos del desarrollo más estables. Son un seguro de vida…

Daily Build & Smoke Test

Control sobre los cambios: contener el potencial de errores en cada compilación del código. Solución: al menos una vez cada día, construir el proyecto (compilarlo) y ejecutar una ristra de Smoke Test. Sobre este patrón Steve Mc Connell sabe mucho, así que si desea obtener más información, el lector puede consultar Code Complete, donde se habla del asunto de forma somera, y Rapid Development: Taming Wild Schedules, donde se trata esta estrategia con mayor profundidad.

Con esto terminamos los patrones. Espero que hayan disfrutado de la serie tanto como yo.

———————————————————-

Referencias:

Steven Berczuk, Brad Appleton: “Software Configuration Management Patterns, Effective Teamwork, Practical Integration

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s