Patrones en Gestión de Configuraciones Software (I)

Existen numerosos tratados sobre el tema que nos atañe hoy, aunque los principales autores son, sin duda, Steve Berczuk y Brad Appleton. Ambos, que se conocieron en una de las numerosas conferencias sobre el tema, decidieron escribir juntos un libro que reuniera sus ensayos y artículos anteriores. El resultado es Software Configuration Management Patterns, Effective Teamwork, Practical Integration.

Este libro trata de recoger todas aquellas prácticas y técnicas que nos ayudan a crear un entorno de construcción software adecuado al proyecto que estemos desarrollando.

Personalmente, no veo adecuada la idea de llamar a estas técnicas “patrones”, puesto que entiendo como patrón una solución concreta, aceptada y comprobada a un problema bien identificado. Yo diría que lo que se presenta en este libro son más bien técnicas, buenas prácticas, etc., porque si aceptamos la idea de Private Workspace como patrón, por ejemplo, entonces las miles de ideas que recoge McConnell en su Code Complete podrían, así mismo, identificarse como patrones, creo yo. Y todo en informática sería “patrones”.
Como ejemplo: problema: ¿Como preveer posibles situaciones caóticas y minimizar sus consecuencias? Solución: Análisis de Riesgos. ¿Es esto un patrón? para mí, no.

Al final, muchos patrones acaban repitiendo una serie de ideas y técnicas que, de llevarse a cabo, estaríamos aplicando tales patrones sin siquiera ser conscientes de ello, con lo cual se podría haber escrito un libro que explicara una serie de técnicas y no andarse con tanta zarandaja. En cualquier caso no soy más que un humilde ignorante, así que si alguien tiene una razón de peso para convencerme de que las ideas recogidas en el libro de Berczuk son patrones y no otra cosa, le pido tenga a bien el explicarme y corregirme.

Realizado este análisis o crítica de la obrita, de unas doscientas páginas, entramos a fondo con los patrones (aceptaré este término puesto que es el que utiliza el autor, y no soy yo nadie para ponerme en su contra). Este repaso nos llevará varios artículos, en los cuales trataré de resumir los patrones, de la forma más escueta y entendible posible. De todos modos, si alguien desea una explicación más extensa de los patrones, gráficos, ejemplos, casos de estudio, etc., siempre puede recurrir al libro original, lo cual recomiendo.

NOTA: En lo que a continuación se presenta, entenderé que el lector está familiarizado con el vocabulario técnico propio de la GCS (Gestión de Configuraciones Software), y que por tanto conoce perfectamente lo que significan palabras como espacio de trabajo, codeline, revisión, versión, etiqueta, rama, control de versiones y merge, así como las operaciones de check-in, check-out y actualización. Si no es así, por favor revise en la Red aquellos términos que no conozca, pues se utilizarán asiduamente.

Clasificación de los patrones

Berczuk y Appleton clasifican sus patrones en dos categorías: aquellos que atienden al espacio de trabajo o workspace y aquellos que tratan sobre el desarrollo del código propiamente o codeline. Entre los primeros, se situarían los patrones Mainline, Active Development Line, Private Workspace, Integration Build, Private System Build, Repository, Third Party Codeline, Task Level Commit, Smoke Test, Unit Test y Regression Test. Entre los segundos tendríamos Private Versions, Release Line, Release Prep Codeline, Task Branch y Codeline Policy.

Los patrones

A continuación presentaremos, en subsecciones para que se visualicen mejor, los distintos patrones, de una forma anotada, informal, sin presentar el problema, fuerzas, solución, interacciones, etc., sino simplemente enumerando las ideas interesantes que conciernen a cada patrón. Para más información, remito nuevamente al lector a hacerse con el libro.

Mainline

El más fundamental de todos. El que da sustento y base al resto. Presenta una política de saber hacer, de cómo organizar y cómo distribuir el código en el control de versiones.

Si abrimos muchas ramas (versiones de producción, distintas plataformas, etc.), luego es realmente problemático tener que reunirlas mediante un merge. No es cuestión de no utilizar ramas, sino de utilizarlas coherentemente y tratando de reunirlas con la rama principal cuanto antes. El patrón aconseja evitar iniciar ramas a partir de otras ramas secundarias, porque el merge sería complejo de realizar. En su lugar, es conveniente crear ramas para versiones de producción (release) y mantener la rama principal para desarrollo, que es la que tiene la mayor parte del trabajo. Así, la mainline es la raíz del proyecto en el control de versiones. Antes de crear una nueva rama para un nuevo release, es conveniente unir la rama del último release con la rama principal.

Otras razones para crear ramas podrían ser: productos paralelos distanciados con el original, en los cuales se tengan previstos pocos merges con la rama principal; integración del trabajo de desarrollo, de este modo el mainline no se detiene y puede progresar añadiendo funcionalidad para un release posterior.

Active Development Line

Este patrón supone como asimilado el patrón Mainline, que acabamos de presentar.

Trata de dar respuesta a la pregunta de cómo gestionar el codeline en el cual está trabajando un grupo de gente de forma simultánea. Para ello, es conveniente hacer que el codeline sea lo más estable posible para que no interfiera con el trabajo de nadie. Esto es particularmente importante en fases de depurado y pruebas, que es cuando más operaciones check-in y check-out se realizan, y en las cuales surgen la mayoría de los problemas.

El acceso exclusivo a un recurso no es una opción, porque sería muy poco eficiente. La solución es crear un Mainline estable y activo; no perfecto, pero sí útil. Instanciar políticas de uso. Para ello, realizar cambios frecuentes, puntos de comprobación bien probados. ¿Qué estabilidad es necesaria? depende de quién usa el codeline, cómo es el ciclo de release, qué mecanismos de pruebas se usan, cuánto (con qué rapidez) evoluciona el sistema, daños de los riesgos que causarían el que algo se rompiera, etc. Es decir: atender a las características del proyecto.

Ojo con las políticas de testado pre-check-in: si son muy largas los programadores las utilizarán con poca frecuencia, alargando tiempos entre check-ins con más cambios en cada uno, y por tanto merges más traumáticos al tener que reunir más cantidad de trabajo. Por ello, alterna tests exhaustivos con otros más ligeros (uno diario, cuatro o cinco diarios, respectivamente), o en épocas de release, abre una rama para no detener la rama principal. Que los test ligeros sean personalizados para cada espacio de trabajo. Periódicamente, integra los espacios de trabajo y ejecuta los test más exhaustivos.

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

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