05/11: Gestión de configuración
- Alberto Barranco Godoy
- 7 nov 2019
- 2 Min. de lectura

La primera hora de la clase del día 5 estuvo dedicada a la charla sobre gestión de configuración de Adrián Sanjuan y José Ramón Cobián. Para sorpresa de todos, comenzaron la charla representando un hipotético problema por un cambio de última hora en un proyecto. Una vez escenificado el conflicto, pasaron a la parte más técnica de la exposición.
Nos explicaron que los cambios son sobre los artefactos (por definición, cualquier cosa suceptible a cambios). Es habitual que al intentar realizar cambios estos no salgan bien, por ello, hay que llevar un control de los cambios (precisamente la Gestión de configuración se encarga de ello). El control de cambios se organiza en las siguientes fases:
Identificar y controlar el cambio
Asegurarse que el cambio es correcto
Informar del cambio
Hay que identificar los Elementos de Configuración del Software, que son los artefactos que podría ser necesario cambiar. Las lineas base son como un punto donde aplicar la gestión de configuración. Existe un estándar oficial que nos indica las lineas base.
En un equipo grande, se genera una petición de cambio, y esta se evalúa sobre si es o no factible de llegar a cabo. Luego se pasa a un equipo, que da la última palabra sobre esto y, si se aprueba, se pone en la cola de cambios. Existe un programa llamado Mantis, que sirve para llevar constancia de los cambios, la cola de cambios.
CONTROL DE VERSIONES:

La segunda parte de la charla comenzó como la primera: con una interpretación de un problema en el proyecto por un cambio de última hora, sin embargo esta vez el problema se basaba en un conflicto muy común, las múltiples versiones de un proyecto. Nos explicaron las dos mejores aproximaciones al control de versiones (centralizado y distribuido) y nos hablaron de los programas más utilizados para ello, por ejemplo GIT nos ayuda a ello. En el distribuido todos los participantes tienen una copia del proyecto, lo que facilita ciertos aspectos pero lleva a conflictos de merge y similares.
Un ejemplo del centralizado es SVN, que tiene una rama principal y ramas (o branches). Los dos modelos poseen acciones comunes: import, checkout, commit, update, log, revisions.
AUDITORÍA DE CONFIGURACIÓN:
Hay que comprobar que se haya hecho el cambio a realizar, que funcione correctamente, además, debe llevarse a cabo una Revisión Técnica Formal, una revisión totalmente técnica (optimización, funcionalidad correcta, etc.) de esta fase se extraen unos informes sobre el cambio (quién lo ha hecho, cómo lo ha hecho, si lo ha hecho bien, etc.), todo esto se sube a una base de datos.
Comentarios