Asignatura: Entornos de programación

Gestión de configuración

Control de versiones, configuración y cambios


Contenido

  1. Introducción
  2. Evolución del software
  3. Conceptos generales
    1. Control de versiones
    2. Control de configuración
    3. Control de cambios
    4. Variantes
    5. Repositorio
  4. Control de versiones
    1. Grafo de evolución simple
    2. Variantes
    3. Propagación de cambios
    4. Fusión de variantes
    5. Técnicas de almacenamiento
    6. Herramientas de control de versiones
    7. Ejemplo: herramienta RCS
  5. Control de configuración
    1. Ejemplo de evolución de una configuración
    2. Problema de coherencia de versiones
    3. Herramientas de control de configuración
    4. Ejemplo: herramienta CVS
  6. Desarrollo mediante cambios sucesivos
    1. Cambios sucesivos, no simultáneos
    2. Desarrollo simultáneo de cambios
    3. Cambios simultáneos de un mismo componente
  7. Control de cambios
    1. Ciclo de vida de cambios
    2. Ejemplo de herramienta: Aegis

Introducción

En este tema se describen las actividades básicas de gestión de configuración y las técnicas y herramientas utilizadas para ello. La terminología empleada para referirse a esta actividad varía según los casos. Por ejemplo:

Control:

Gestión:

Evolución del software

La necesidad de gestionar la configuración surge del hecho de que el software evoluciona con el tiempo:

Conceptos generales

Control de versiones

Utilizaremos este término para referirnos a la evolución de un único elemento, o de cada elemento por separado.

Control de configuración

Con este término nos referiremos a la evolución de un conjunto de elementos.

Control de cambios

Es un concepto relacionado con la metodología de desarrollo de software. Se trata de hacer el desarrollo de forma evolutiva, mediante cambios sucesivos realizados de una manera disciplinada.

Variantes

Repositorio

Control de versiones

Como se ha dicho, se refiere a la evolución de un único elemento, o de cada elemento por separado si son varios.

La evolución puede representarse gráficamente en forma de grafo, en el que los nodos son las versiones y los arcos corresponden a la creación de una nueva versión a partir de otra ya existente.

Grafo de evolución simple

Las revisiones sucesivas de un componente dan lugar a una simple secuencia lineal.

revisiones

Esta forma de evolución no presenta problemas desde el punto de vista de organización del repositorio. Las versiones se pueden designar simplemente mediante números correlativos, como en la figura.

Variantes

Cuando hay variantes, es decir, cuando existen simultáneamente varias versiones del componente, el grafo de evolución ya no es una secuencia lineal, sino que adopta la forma de un árbol. Si queremos seguir numerando las versiones se necesitará ahora una numeración a dos niveles. El primer número designa la variante (línea de evolución), y el segundo la versión particular (revisión) a lo largo de dicha variante.

variantes

La terminología usada para referirse a los elementos del grafo es la propia de un árbol:

Propagación de cambios

Cuando se tienen variantes que se desarrollan en paralelo suele ser necesario aplicar un mismo cambio a varias variantes. Podemos empezar por realizar el cambio en una rama y luego propagarlo a las otras.

propagación de cambios

Hay herramientas concretas que permiten automatizar la propagación del cambio. Se denominan “Diff-Merge”. Usando una notación matemática ("-" para la diferencia entre versiones y "+" para la aplicación de un cambio) podríamos escribir:

2.4 = 2.3 + (1.5 - 1.4)
3.3 = 3.2 + (1.5 - 1.4)

La nueva versión se obtiene a partir de otras tres. Esta acción se denomina mezcla de tres vías (three-way merge).

Fusión de variantes

En determinados momentos puede dejar de ser necesario mantener una rama independiente. En este caso se puede fundir con otra (MERGE), y el árbol de evolución pasa a ser un grafo convencional.

fusion

Para fundir variantes se puede operar de forma similar a la propagación de cambios, aplicando a una rama los cambios independientes hechos en la otra. Por ejemplo:

4.1 = 2.3 + (3.2 - 2.2),  o bien
4.1 = 3.2 + (2.3 - 2.2)

También se pueden combinar manualmente o mediante alguna herramienta las dos versiones finales para crear la nueva versión común. Esta acción se denomina mezcla de dos vías (two-way merge).

Técnicas de almacenamiento

En la mayoría de los casos las distintas versiones tienen en común gran parte de su contenido. Almacenar cada versión completa por separado desaprovecha bastantes recursos, en comparación con la posibilidad de almacenar cada fragmento de información distinto sólo una vez aunque aparezca repetido en diferentes versiones. Existen distintas técnicas para organizar el almacenamiento combinado del conjunto de versiones de una manera eficiente. Se apoyan en herramientas del tipo diff o diff-merge.

Herramientas de control de versiones

Como ejemplo de herramientas de control de versiones se pueden citar:

En realidad estas herramientas ya no se usan, y en su lugar normalmente se trabaja con sistemas de control de configuración, que manejan conjuntos de ficheros y no cada uno por separado.

Ejemplo: herramienta RCS

RCS

Control de configuración

Como se ha dicho antes, aplicaremos esta denominación al control de la evolución de un conjunto de elementos.

Ejemplo de evolución de una configuración

Se presenta un ejemplo de evolución simple (secuencia temporal lineal). Las revisiones del conjunto se han numerado correlativamente (Rev.1, Rev.2, ...). Cada configuración contiene una colección de elementos, no siempre los mismos. Pueden crearse o eliminarse elementos entre una revisión y la siguiente. Los cambios individuales de un componente se indican con flechas. Los componentes que se mantienen sin cambios se marcan con dos líneas paralelas (como el signo = en vertical).

evolución de una configuración

Problema de coherencia de versiones

La primera dificultad del control de configuración, respecto al control de versiones, es cómo nombrar las versiones de los componentes individuales. Si se numeran las versiones de los componentes con independencia de la evolución del conjunto tendríamos lo siguiente:

consistencia de versiones individuales

O bien, dibujando repetidas las versiones que se mantienen sin cambios en cada revisión del conjunto:

consistencia de versiones individuales

Como puede verse la numeración de las versiones individuales no tiene una relación sencilla con la numeración de las versiones del conjunto. Hace falta mantener una tabla o índice que asocie cada versión del conjunto con las versiones individuales de sus componentes.

Herramientas de control de configuración

Hay diversos ejemplos de herramientas de software libre para control de configuración:

Ejemplo: herramienta CVS

La figura muestra las órdenes e intercambio de datos entre:

CVS

Las órdenes principales son:

Desarrollo mediante cambios sucesivos

Las herramientas de control de configuración facilitan desarrollar software de manera evolutiva, mediante cambios sucesivos aplicados a partir de una configuración inicial (que puede ser vacía) hasta llegar a una versión final aceptable del producto. En lo que sigue se planteará el desarrollo como una evolución simple (secuencia de revisiones) de la línea base. En la práctica suele ser necesario contemplar también la gestión de variantes.

Cambios sucesivos, no simultáneos

Si los cambios se realizan estrictamente uno tras otro, entonces no hay ningún problema para realizarlos. En el siguiente ejemplo se realizan cambios sobre copias de trabajo de ciertos componentes, que luego se almacenan como parte del repositorio, actualizando la línea base. Partiremos de la situación en que el primer cambio ha generado ya una línea base no vacía.

Desarrollo simultáneo de cambios

En la práctica no es posible esperar a que termine un cambio para empezar el siguiente. El trabajo en equipo exige desarrollar simultáneamente más de un cambio a la vez. Para evitar complicaciones lo que sí se suele hacer es integrar los cambios en el repositorio de uno en uno según se van completando, con independencia de cuándo se haya iniciado cada uno.

Cambios simultáneos de un mismo componente

Las cosas se complican cuando dos cambios simultáneos modifican un mismo componente. Tras integrar el primer cambio hay que propagar las modificaciones del componente común al otro cambio, todavía en desarrollo.

Control de cambios

La ingeniería de software recomienda realizar el desarrollo de manera disciplinada. Las herramientas de control de versiones no garantizan un desarrollo razonable si cualquier miembro del equipo puede realizar los cambios que quiera e integrarlos en el repositorio sin ningún tipo de control.

Ciclo de vida de cambios

Para garantizar que siempre disponemos de una línea base adecuada para continuar el desarrollo es necesarios aplicar controles al desarrollo e integración de cambios. El siguientes esquema muestra el ciclo de vida de cambios soportado por la herramienta Aegis, que fuerza esta disciplina de desarrollo.

Ciclo de cambio en Aegis

Ejemplo de herramienta: Aegis

A continuación se presenta un esquema de organización del trabajo bajo la herramienta Aegis, usando directorios separados para cada parte de la actividad de cambio.

Despliegue de Aegis