top of page

05/11: Gestión de configuración

  • Foto del escritor: Alberto Barranco Godoy
    Alberto Barranco Godoy
  • 7 nov 2019
  • 2 Min. de lectura

ree

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:

  1. Identificar y controlar el cambio

  2. Asegurarse que el cambio es correcto

  3. 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:


ree

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.



Documentos adjuntos:




Comentarios


Síguenos y suscribete

  • Instagram - Círculo Blanco
  • YouTube - círculo blanco

Suscripción e-mail

Gracias por suscribirte

bottom of page