Patrones en Gestión de Configuraciones Software (II)

Private Workspace

Cuando el objetivo fundamental es trabajar en entornos cambiantes, como por ejemplo un desarrollador que debe retomar el trabajo de otro, es neceasario aislar el trabajo propio del realizado por el resto. Para lograr esto, evitando además inconsistencias en las copias locales de cada programador, tenemos este patrón.

Actualizar cada mínimo cambio que se realiza no parece muy eficiente. Parece más útil manejar un espacio de trabajo privado, que permita decidir cuándo y cómo cambiar el entorno para actualizar los cambios propios. Estos espacios de trabajo solamente contendrán los archivos que modifica cada individuo, junto con copias (que en principio no será necesario modificar) de los archivos del resto de desarrolladores. Aquellos archivos comunes que apenas cambian o afectan a todos deberían estar en el control de versiones, pero no en espacios de trabajo privados.

La forma de actuar sería actualizar a la última versión antes de empezar a trabajar. También sería muy útil mantener un espacio de trabajo privado diferente para cada rama en la cual se vaya a trabajar. Antes de hacer una protección (o checkin), se verificaría que el entorno no se ve afectado por los cambios realizados; para ello, habría que volver a actualizar, para asegurarnos.

Si los cambios realizados van a llevar demasiado tiempo, quizá sea bueno actualizar más a menudo, con mayor frecuencia.

La idea del Private Workspace yo la entiendo como una “caja de arena”.

Repository

¿Cómo obtener las versiones adecuadas de los componentes deseados a la hora de crear un nuevo espacio de trabajo? ¿Cómo recuperar versiones y revisiones antiguas, etc.? Sería útil, además, tener una traza de los cambios para cada artefacto, revisión a revisión. Teniendo un sólo punto de acceso (el repositorio), es más sencillo y transparente la creación de nuevos espacios de trabajo. El mismo control de versiones sirve para aplicar este patrón. Para aplicarlo, crea y etiqueta cada versión para que sea sencillo descargar estas versiones en nuevos espacios de trabajo. Utiliza versiones y ramas de forma coherente.

Private System Build

Este patrón enfoca el problema de cómo verificar que los cambios locales realizados por un individuo no afectan al sistema de forma nociva. ¿Qué elementos externos al trabajo local (pero relativos al proyecto) se verán afectados por los cambios realizados? Antes de subir los cambios al repositorio, realiza una construcción local (private build) de todo el sistema para ver si todo funciona correctamente. Tal construcción debe imitar lo más fielmente posible la construcción real del sistema: misma estructura de directorios, mismas dependencias, etc. Es decir, una construcción muy similar al nighty build (construcción automática de todo el sistema que se realiza diariamente por las noches, que es cuando el sistema tiene menos carga de trabajo).

Si el sistema es demasiado grande, se pueden realizar construcciones incrementales, con la posibilidad de excluir artefactos que no afecten de ningún modo. En caso de encontrar un error o conflicto entre el trabajo local y el de otros, realizar un merge cuidadosamente y hablar con el desarrollador de cuya parte del código existe tal conflicto.

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

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