Gestin de configuracin

Publicado en Lunes, 17 marzo 2008

La gestin de configuracin es un nombre rimbombante para denominar el conjunto de
procedimientos que permiten controlar los cambios realizados sobre un producto. Definido de
modo coloquial, permite controlar los cambios que generan las diferentes versiones.
Durante el desarrollo de cualquier producto, no solamente del cdigo de un programa, ste
evoluciona mientras se realizan sucesivos cambios en l. Sin ir ms lejos, un libro no se escribe
entero en un par de horas sino que se prolonga durante un nmero de sesiones indeterminadas
durante las cuales se aade ms y ms contenido. Esta adicin de contenido realmente son
cambios sucesivos al documento. Evidentemente, no todos los cambios consisten en adicciones
sino que muchas veces se modifican o eliminan partes ya existentes por diversos motivos.
Independientemente del tipo de cambio realizado, los cambios no son siempre definitivos ni
correctos. En muchos casos, un cambio introduce un error que es corregido con cambios
posteriores pero, en algunos casos, se deseara poder deshacer completamente un cambio
errneo. En estas circunstancias es cuando interviene la gestin de configuracin.
Mediante los procesos definidos en la gestin de configuracin, es posible trazar los cambios
que se han realizado en el tiempo. Al disponer de esta informacin, es posible identificar y
controlar todos y cada uno de los cambios realizados. Asimismo, es posible regenerar sin
errores el estado del producto en cualquier momento de su desarrollo, es decir, cualquiera de
sus versiones.
La implantacin de la gestin de configuracin puede parecer complejo en un inicio pero
simplifica enormemente el trabajo a corto plazo. Una vez implantado se transforma en una
herramienta indispensable de trabajo.
Existen mltiples formas de implementar la gestin de configuracin. En un par de prcticas de
la carrera se implementa un proceso manual basado en formularios de peticin de cambio sobre
la lnea base (la ltima versin existente) que se cumplimentaban, evaluaban, implementaban y
revisaban. Este procedimiento manual es completamente intil y ocasiona una gran sobrecarga.
Para implantar la gestin de configuracin, lo mejor es utilizar una herramienta que automatice
el proceso. El uso de estas herramientas hace que aplicar la gestin de configuracin tenga un
coste cercano a cero pero proporciona todas las ventajas del proceso.
En el siguiente captulo de esta serie, se describirn estas herramientas en profundidad antes de
describir cmo implantar y utilizar una de ellas.
Resumen
En el presente trabajo se expone una gua para implantacin de la herramienta de software libre para
la automatizacin del proceso de Gestin de Configuracin "Subversion".
PALABRAS CLAVES
Software libre, Gestin de Configuracin.
ABSTRACT
This paper concerns the implementation procedure of a free software tools for the Configuration Managmente
automation "Subversion".
KEY WORDS
Free Software, Configuration Management.
LISTADO DE ABREVIATURAS Y SIGLAS
SSL: Sockets Security Level (Nivel de Sockets de Seguridad).
HTTP: Hipertext Transfer Protocol (Protocolo de Transferencia de Hipertextos).
Introduccin
Durante el desarrollo de cualquier producto, no solamente del cdigo de un programa, ste evoluciona
mientras se realizan sucesivos cambios en l. Por ejemplo, un libro no se escribe entero en un par de horas,
sino que se prolonga durante un nmero de sesiones indeterminadas durante las cuales se aade ms y ms
contenido. Esta adicin de contenido realmente son cambios sucesivos al documento. (Wordpress, 2008).
Evidentemente, no todos los cambios consisten en adicciones sino que muchas veces se modifican o eliminan
partes ya existentes por diversos motivos. Independientemente del tipo de cambio realizado, los cambios no
son siempre definitivos ni correctos. En muchos casos, un cambio introduce un error que es corregido con
cambios posteriores pero, en algunos casos, se deseara poder deshacer completamente un cambio errneo.
En estas circunstancias es cuando interviene la gestin de configuracin.
Mediante los procesos definidos en la gestin de configuracin, es posible trazar los cambios que se han
realizado en el tiempo. Al disponer de esta informacin, es posible identificar y controlar todos y cada uno de
los cambios realizados. Asimismo, es posible regenerar sin errores el estado del producto en cualquier
momento de su desarrollo, es decir, cualquiera de sus versiones.
La implantacin de la gestin de configuracin puede parecer complejo en un inicio pero simplifica
enormemente el trabajo a corto plazo. Una vez implantado se transforma en una herramienta indispensable de
trabajo.
Existen mltiples formas de implementar la gestin de configuracin. Una alternativa podra ser implantar un
proceso manual basado en formularios de peticin de cambio sobre la lnea base (la ltima versin existente)
que se cumplimentan, evalan, implementan y revisan. Este procedimiento manual es completamente intil y
ocasiona una gran sobrecarga.
Para implantar la gestin de configuracin, lo mejor es utilizar una herramienta que automatice el proceso. El
uso de estas herramientas hace que aplicar la gestin de configuracin tenga un coste cercano a cero pero
proporciona todas las ventajas del proceso.
En los siguientes epgrafes se describen algunos de los conceptos bsicos de la Gestin de Configuracin de
Software, as como se presenta una gua para la implantacin de la herramienta de software libre para la
automatizacin de este proceso "Subversion".
Conceptos asociados a la gestin de la configuracin de
software
GESTIN DE LA CONFIGURACIN DE SOFTWARE. OBJETIVOS Y ACTIVIDADES.
La integridad de un producto software depende de la accin combinada de tres tipos de disciplinas:
Desarrollo, Gestin y Control.
Dentro de las disciplinas de control se encuentra la Gestin de la Configuracin del Software (GCS),
cuyo objetivo es establecer y mantener la integridad de los componentes generados durante un proyecto de
desarrollo software y a lo largo de todo el ciclo de vida del producto, evaluar y controlar los cambios sobre
ellos, es decir, controlar la evolucin del sistema y facilitar la visibilidad del producto. Esta suele ser
considerada como una actividad de Garanta de la Calidad, por tanto, una buena GCS influye en gran medida
en la calidad final del producto de software.
Para conseguir los objetivos mencionados anteriormente, la GCS plantea la realizacin de las siguientes
actividades:
Identificacin de la Configuracin: consiste en identificar la estructura del producto, sus componentes y el tipo
de estos, y en hacerlos nicos y accesibles de alguna forma.
Control de Cambios en la Configuracin: consiste en controlar las versiones y entregas de un producto y los
cambios que se producen en l a lo largo del ciclo de vida.
Generacin de Informes de Estado: consiste en informar acerca del estado de los componentes de un
producto y de las solicitudes de cambio, recogiendo estadsticas acerca de la evolucin del producto.
Auditora de la Configuracin: consiste en validar la completitud de un producto y la consistencia entre sus
componentes, asegurando que el producto es lo que el usuario quiere.
Sin embargo, los sistemas que automatizan la GCS suelen incluir algunas funciones adicionales, lo que lleva a
ampliar la definicin estndar con las siguientes actividades:
Construccin: consiste en gestionar la compilacin y enlazado de los distintos componentes del
producto software de una forma lo ms eficiente posible.
Control del Trabajo en Equipo: consiste en controlar las interacciones que se producen entre los mltiples
desarrolladores de un producto, sobre todo cuando deben compartir ciertos componentes del producto.
Control de Versiones: consiste en mantener un registro histrico de las diferentes versiones por las que pasan
los componentes de un producto, que permita la recuperacin de cualquiera de ellas.
Gestin de Problemas: consiste en realizar un seguimiento de la evolucin de los problemas que afectan al
producto.
Configuracinn de software. Elementos de configuracin de
software.
Al conjunto de toda la informacin y productos utilizados o producidos en un proyecto como resultado
del proceso de Ingeniera de Software se le denomina Configuracin de Software.
A cada uno de los componentes de la Configuracin del Software se le va a llamar Elemento de Configuracin
de Software (ECS). El ECS es la unidad de trabajo para la GCS.
El trmino Configuracin de Software designa, por tanto, el conjunto de todos los ECS de un proyecto. Se
pueden considerar como ECS los siguientes componentes:
La especificacin del sistema.
El plan del proyecto software.
La especificacin de requisitos software.
Un prototipo, ejecutable o en papel.
El diseo preliminar.
El diseo detallado.
El cdigo fuente.
Programas ejecutables.
El manual de usuario.
El manual de operacin e instalacin.
El plan de pruebas.
Los casos de prueba ejecutados y los resultados registrados.
Los estndares y procedimientos de ingeniera de software utilizados.
Los informes de problemas.
Las peticiones de mantenimiento.
Los productos hardware y software utilizados durante el desarrollo.
La documentacin y manuales de los productos hardware y software utilizados durante el desarrollo.
Diseos de bases de datos.
Contenidos de bases de datos.
Entre otros.
Para cada uno de estos elementos se almacenar al menos nombre, versin, estado y localizacin. En
cualquier caso, para cada proyecto concreto se debe determinar qu se va a considerar como ECS.
Ahora bien, un ECS debe ser un elemento que se pueda definir y controlar de forma separada. Es decir, debe
ser una unidad en s mismo.
LINEA BASE.
Como se mencion anteriormente, uno de los objetivos principales de la GCS es gestionar los cambios que se
producen en el sistema a lo largo de su ciclo de vida.
Para controlar los cambios sin impedir los cambios justificados se utiliza el concepto de Lnea Base.
Se puede definir una lnea base como un punto de referencia en el proceso de desarrollo del software que
queda marcado por la aprobacin de uno o varios ECS, mediante una revisin tcnica formal. Tambin se
puede definir como un elemento que ha sido revisado y aceptado, que va a servir como base para otros
desarrollos posteriores y que solamente puede cambiarse a travs de un proceso formal de control de
cambios.
La idea consiste en permitir cambios rpidos e informales sobre un ECS antes de que se pase a formar parte
de una lnea base, pero en el momento en que se establece una lnea base se debe aplicar
un procedimiento formal para evaluar y verificar cada cambio.
Auditoria de la configuracin.
Cmo se puede asegurara que el cambio se implement correctamente? Con revisiones tcnicas formales
y auditorias de configuracin del software.
Las revisiones tcnicas se centran en la correccin tcnica del ECS que ha sido modificado. Se deben llevar
a cabo para cualquier cambio que no sea trivial. Una auditoria de configuracin complementa la revisin
tcnica al comprobar caractersticas que generalmente no tiene en cuenta la revisin, se plantea y responde
las siguientes preguntas:
Se ha hecho el cambio especificado?
Se llevo una revisin tcnica?
Se ha seguido el proceso del software y se han aplicado los estndares de ingeniera del software?
Se han resaltado los cambios en el ECS?
Se han seguido procedimientos de GCS para sealar el cambio, registrarlo y divulgarlo?
Se han actualizado todos los ECS relacionados?
Informe de estado.
Responde a las siguientes preguntas:
Que paso?
Quien lo hizo?
Cuando paso?
Que ms se afecto?
Los informes de estado deben realizarse para todos los cambios y cosas que se le hagan al software por
cada uno de los desarrolladores, as todos estn al tanto de lo que se va haciendo, de esta forma se evita el
sndrome de la mando izquierda ignora lo que hizo la derecha, y un desarrollador va a cambiar lo que otro ya
hizo.
Versiones, revisiones y releases
Se puede definir una Versin como una instancia de un elemento de configuracin, en un momento dado del
proceso de desarrollo, que es almacenada en un repositorio, y que puede ser recuperada en cualquier
momento para su uso o modificacin.
A las distintas versiones que aparecen en el tiempo, segn se va avanzando en el desarrollo de un elemento,
se les suele llamar tambin Revisiones.
Entre las distintas revisiones de un elemento de configuracin se pueden establecer relaciones de sucesin
temporal. Una representacin posible para las diferentes revisiones de un elemento y sus relaciones de
sucesin es mediante un Grafo de evolucin o Grafo de revisin.
La manera ms fcil de crear una nueva revisin de un ECS es realizar una modificacin sobre la revisin
ms reciente. De esta manera las revisiones van formando una cadena, a la que se suele llamar Cadena de
Revisin. Cada revisin en la cadena es una actualizacin y viene a sustituir a la revisin anterior.
Normalmente se trabajar sobre la ltima revisin de la cadena, que es la ms actual, aunque las anteriores
tambin deben ser accesibles.
Cada una de las revisiones de un ECS se debe poder identificar de manera nica, siendo comn utilizar un
esquema numrico, donde cada nueva versin recibe un nmero sucesivo.
Se suele llamar Release a una configuracin del sistema que se va a comercializar o entregar al cliente.
Almacenamiento de versiones
Existen varias variantes para almacenar las versiones que se van obteniendo de un elemento de
configuracin. Una posibilidad es almacenar nicamente la ltima versin de cada uno de los ECS del
sistema, pero esto puede ocasionar numerosos problemas.
A veces se tiene que versiones anteriores siguen formando parte de sistemas que estn todava en uso, por lo
que hay que seguir mantenindolas, a pesar de tener versiones nuevas ms actualizadas.
Otras veces puede ser conveniente guardar versiones anteriores como punto de seguridad, al cual poder
volver en caso de que un cambio efectuado no ofrezca el resultado deseado. Tambin puede ser conveniente
guardar versiones antiguas para poder reutilizar elementos que aparecan en ellas pero que fueron
desechados en un momento dado.
Las herramientas de control de versiones o gestin de revisiones ayudan a crear, identificar y almacenar
nuevas versiones, al mismo tiempo que se mantienen las versiones anteriores.
Sistemas de control de versiones.
Cuando se plantea la implantacin de mecanismos de gestin de configuracin, existen mltiples alternativas
que deben ser estudiadas segn las necesidades de cada caso.
La primera alternativa, aunque la ms desaconsejable, es la gestin manual. En este caso, la lnea base es la
ltima versin del producto. Para modificar dicha versin es necesario formular una peticin de cambio
cumplimentando el formulario definido. Esta peticin de cambio es evaluada por un comit para determinar la
idoneidad de su implantacin y, si es aceptada, se implementa generando una nueva versin. Evidentemente,
para evitar que se pierda la versin anterior, es necesario almacenar una copia y es donde surgen los ficheros
con nombres segn la versin, fechas, ficheros comprimidos con versiones.
Esta alternativa tiene algunos aspectos bastante negativos: su gran sobrecarga, la facilidad con la que el
sistema se rompe con lo que es invalidado y la lentitud que supone la burocracia en el proceso de cambio. Su
nico punto favorable es que es 100% adaptable a las necesidades.
Evidentemente, esta alternativa no es muy viable en la prctica. Sin embargo, existen herramientas que se
encargan de automatizar prcticamente todas las tareas: los sistemas de control de versiones.
Los sistemas de control de versiones son programas que se encargan de controlar y gestionar los distintos
cambios que se producen en el producto. Este producto puede ser desde el cdigo de un programa,
hasta documentos de texto, diagramas, imgenes, planos, etctera.
Todos los sistemas de control de versiones se basan en el concepto repositorio. Un repositorio no es ms que
el conjunto de versiones del producto. Una vez creado, los distintos usuarios realizan sus cambios sobre el
repositorio que se encarga de almacenarlos permitiendo la recuperacin de cualquier versin. Existen dos
tipos de repositorios:
Centralizado:
El repositorio es nico y reside en una mquina accesible por cualquier usuario. Este es el modelo ms usual.
Distribuido:
En este caso, existen mltiples repositorios accesibles por cada usuario. Cada usuario utiliza un repositorio
cualquiera y existen mecanismos de sincronizacin entre repositorios.
En cualquiera de los dos casos, el repositorio es compartido por todos los usuarios (o al mismo usuario desde
distintas mquinas) que tengan acceso al mismo. Es posible que se produzcan ediciones simultneas de los
mismos elementos que generen conflictos. Para solucionar este problema existen dos polticas bsicas de
resolucin de conflictos:
bloqueo-modificacin-desbloqueo:
En esta poltica se evitan las modificaciones concurrentes. Cuando un usuario desea realizar una
modificacin, indica el elemento a modificar que queda bloqueado en el repositorio por lo que se impide el
acceso al resto de usuarios (exclusin mutua). Cuando finaliza de realizar sus cambios, los enva al
repositorio liberando el bloqueo con lo que el resto de los usuarios puede obtener la copia actualizada para
realizar sus propios cambios.
copiar-modificar-mezclar:
Esta poltica permite las modificaciones simultneas. Cada usuario hace una copia del repositorio en su
mquina y procede trabajar con ella como si no fuera un repositorio. Cuando finaliza su trabajo, enva los
cambios al repositorio que se encarga de analizar los cambios realizados por el usuario y los que se han
realizado en el propio repositorio y realiza la mezcla.
Evidentemente, la primera poltica es mucho ms restrictiva lo que dificulta el trabajo diario ralentizando el
acceso a los recursos y ocasionando problemas si no se liberan recursos bloqueados. La segunda, por su
parte, tiene como inconveniente que no siempre es posible mezclar los cambios realizados aunque en esos
casos, utiliza al usuario que enva cambios para solucionar esos conflictos irresolubles automticamente.
Existen numerosas aplicaciones para controlar versiones: CVS, Sourcesafe, Subversion, entre otras, cada una
con sus caractersticas nicas. En el prximo epgrafe se abordar una de las ms populares "Subversion".
Sistemas de control de versiones: Subversion.
De los mltiples sistemas existentes, uno de los ms tiles y utilizados es Subversion (SVN) . SVN surge para
reemplazar al gestor usado en sistemas Unix (CVS) con el objetivo de mejorar algunos aspectos que
dificultaban el uso de la aplicacin. Existen versiones tanto del cliente como del servidor para cualquier
plataforma.
El servidor de Subversin gestiona un repositorio centralizado con la poltica copiar-modificar-mezclar. Sin
embargo, existen herramientas para sincronizarlo con otros repositorios y es posible configurar repositorios
con la poltica bloquear-modificar-desbloquear. Las caractersticas fundamentales son:
Nmero de versin global al repositorio que se incrementa con cada cambio, por lo que es posible volver a
una versin anterior indicando dicho nmero global.
Control de cambios en ficheros y directorios (si, almacena y controla cambios en rboles completos de
carpetas y ficheros). Mantiene el histrico de versiones de un fichero aunque se mueva o renombre.
Detecta y trata apropiadamente los ficheros binarios, uno de los puntos dbiles de CVS. A estos ficheros les
aade una propiedad indicando su tipo.
La transmisin entre cliente y servidor incluye nicamente los cambios lo que supone un ahorro del ancho de
banda. Adems, los cambios se calculan a nivel de byte (en lugar de lnea ampliamente usado) lo que reduce
an ms el tamao de las modificaciones.
Por su parte, es posible acceder al servidor utilizando distintos clientes independientemente de la plataforma
en la que ejecute cada uno de ellos. Es posible utilizar un cliente en Windows que se conecte con un servidor
en Unix o Mac y viceversa. Esta facilidad, permite la creacin de clientes bastante avanzados adaptados a
cada plataforma como, por ejemplo, la integracin con documentos de office que dispone el cliente de
Windows.
El uso de subversin es muy sencillo. El proceso si se usa una consola es:
svn co ruta_repositorio [destino]
Descarga una copia (checkout) de cualquier carpeta contenida en el repositorio (no es necesario bajar la raz
del repositorio, se puede bajar cualquier carpeta contenida en el mismo) que se denominar copia de trabajo.
La copia de trabajo son ficheros locales en la mquina por lo que puede ser modificada segn se desee.
Las rutas de repositorio tienen la forma protocolo://usuario:password@servidor/ruta. Existen
mltiples protocolos como Webdav, svn (protocolo propio), svn+ssh (protocolo svn a travs de un tnel ssh
para asegurarlo
svn update
Se encarga de descargar los ltimos cambios del repositorio y mezclarlos en la copia de trabajo para que
coincida con la ltima versin disponible.
Si en el proceso de mezcla se detectan conflictos irresolubles, se marcan en la copia de trabajo para que el
usuario los resuelva. De esta forma, se evita corromper el repositorio.
svn ci [ruta]
Cuando se finalizan los cambios se envan al repositorio (commit). En este momento, se comprueba si la
versin base del usuario es la ltima del repositorio y si es as se envan los cambios creando una nueva
revisin.
Si las versiones no coinciden, el usuario deber actualizar (update) su copia de trabajo con lo que se
marcarn los conflictos en la copia de trabajo.
Adems de este cliente de consola, existen aplicaciones grficas que realizan ese trabajo de forma
transparente y ms agradable para el usuario.
Si se utiliza Windows, la opcin ms adecuada es TortoiseSVN. Es un cliente que se integra con el explorador
de Windows y que permite realizar todas las acciones mediante entradas en el men contextual de los
ficheros y carpetas.
Para el escritorio KDE existe un plugin similar denominado kdesvn aunque no implementa toda su
funcionalidad. Sin embargo, para un uso habitual es suficientemente til.
Repositorios en Subversion.
Como ya se plante anteriormente, SVN es un sistema de control de versiones con la poltica copiar-
modificar-mezclar con gran proyeccin en la actualidad. Por ejemplo, SourceForge (una forja
de proyectos libres) utiliza SVN como control de versiones. Gran parte del xito de SVN se debe a su agilidad
cuando intervienen varias personas, debido a su poltica, y a su flexibilidad que no lo limita a desarrollos de
software: es posible almacenar planos, imgenes, libros, etctera.
Pero esta flexibilidad puede volverse en contra del usuario: al crear el repositorio en su interior no existe
absolutamente nada y nos encontramos ante el "sndrome de la hoja en blanco". Para poder extraer el
mximo partido a la herramienta es necesario definir una estructura de directorios en la que se almacene la
informacin. Y hay algunas mejores que otras.
Aunque no es obligatorio, prcticamente todos los proyectos de SVN tienen un primer nivel comn. Las
polticas aplicadas en este nivel proporcionan coherencia en la gestin y funcionalidades no disponibles de
forma nativa. Esta estructura se compone de tres directorios (branches, tags y trunk) y una cuarta opcional
(vendor). Es necesario definir cmo funcionan y se usan cada uno de ellos, cmo se gestionan mltiples
proyectos, entre otras cosas.
Estructura o layout del repositorio.
Ya se ha creado el repositorio por lo que se tiene la "hoja en blanco" en revisin 0. Es el momento de hacer el
primer commit que dar lugar a la revisin 1, la ms importante de todas ya que definir el funcionamiento
futuro del repositorio. Esta revisin crea la estructura raz del repositorio y el funcionamiento global del mismo.
Tras multitud de experiencias, lo ms recomendable para este primer commit es crear tres directorios o
carpetas: branches, tags y trunk. Si est previsto utilizar algo desarrollado por terceras personas se debera
crear un cuarto directorio: vendor.
El tronco o rama principal: trunk
Este directorio contiene la versin actual de trabajo sobre la que se realizan las modificaciones, es decir, el
cdigo/documentos/imgenes sobre las que se est trabajando en este momento.
Es la zona de trabajo habitual en la que los desarrolladores realizan sus modificaciones.
Como poltica adicional esta rama siempre tiene que tener algo correcto: si es un programa debe compilar, si
es un documento en LaTeX debe poder convertirse. En los ltimos tiempos se utilizan tcnicas de integracin
continua para asegurar el cumplimiento de esta poltica.
Las hojas ms importantes: tags
Cuando en la rama principal (trunk) se tiene una versin que se va a entregar al cliente habitualmente es
necesario registrar cul es para poder volver a ella en caso de problemas. SVN no proporciona un mecanismo
integrado para realizar esta tarea por lo que se surgen dos opciones:
Tener un fichero que almacene la versin del repositorio que debe gestionarse. Esta opcin es poco
recomendable.
"Copiar" la versin actual del trunk en la carpeta tags (svn cp repositorio/trunk repositorio/v.vv.vv).
La segunda opcin es la ms recomendable ya que suprime las necesidades de gestin al mximo. Adems,
hay que destacar que la copia no es tal ya que, al no existir modificacin en el fichero, SVN no copia los datos
sino punteros para utilizar los mismos ficheros.
Aunque es posible realizar modificaciones sobre tags, se recomienda mantenerlas inmutables.
El laboratorio: branches
Cuando se quiere hacer algn tipo de prueba, trabajo que pueda corromper la rama principal o gestionar
cambios en una versin vieja que est en mantenimiento se puede trabajar fuera del repositorio (poco
recomendable y, dependiendo de la envergadura del trabajo, puede ser muy difcil volver a integrarlo en la
principal) o utilizar una rama. El proceso habitual es copiar el trunk a una subcarpeta de branches, realizar
los experimentos(subiendo las versiones necesarias) y, si son exitosos, mezclar los cambios con el trunk para
seguir el desarrollo.
Estas ramas pueden crearse o destruirse segn las necesidades y mezclar cambios con cualquier otra rama
sin demasiados problemas. Adems, la poltica de mantener la rama incorrupta no se aplica en las ramas lo
que proporciona mayor libertad y permite usar una rama para almacenar una serie de pasos que dejaran
corrupta la rama principal.
Aprovechando el conocimiento universal: vendor
Es habitual utilizar trabajo realizado por terceras personas (bibliotecas en un lenguaje de programacin, un
trabajo de universidad de otro compaero) que es necesario controlar. Para integrarlas en SVN se utilizan
las ramas de proveedor.
La poltica de estas ramas permite almacenar el conjunto de versiones de las bibliotecas e integrarlas de
forma transparente en el cdigo propio. Adems, permiten realizar modificaciones personales sobre
la biblioteca e integrarlas con las futuras versiones de la misma.
La gestin se compone de los siguientes pasos:
Importar la versin actual:svn import ruta/biblioteca repositorio/vendor/biblioteca/current m: importar
biblioteca vX.YY.
Etiquetar la versin:svn copy repositorio/vendor/biblioteca/current repositorio/vendor/biblioteca/X.YY
m: Etiquetar biblioteca vX.YY.
Integrarla en la rama principal:svn copy repositorio/vendor/biblioteca/X.YY repositorio/trunk/libs/ -m: Aadir
biblioteca vX.YY a la rama principal.
Cuando se quiere integrar una nueva versin de la biblioteca, se modifica la versin current, se etiqueta y se
utiliza svn merge para aadir los cambios.
Un caso especial son las bibliotecas ya gestionadas en un repositorio SVN al que se tiene acceso. En este
caso, si no se va a realizar ninguna modificacin en el cdigo o si se dispone de la posibilidad de modificar el
repositorio externo, es posible enlazar directamente el repositorio de la biblioteca utilizando utilizando
repositorios externos. En este caso, basta con definir la propiedad svn:external como biblioteca repositorio
para que SVN descargue el cdigo externo de forma transparente.
Un repositorio por proyecto o mltiples proyectos en un repositorio.
Esta es la duda eterna en el uso de SVN. Existen argumentos a favor y en contra de cada una de las dos que,
puestos en una balanza, no arrojan un claro vencedor. Para no alargar en exceso se expone opcin que, de
forma absolutamente personal, parece ms til: mltiples repositorios.
La idea es que cada proyecto tenga su propio repositorio con la estructura estndar en su raz. De esta forma
toda la informacin relacionada con el proyecto est controlada y gestionada con las mismas polticas,
simplifica la migracin y tiene un nmero de revisin nico.
El principal punto en contra son las piezas comunes entre proyectos: quin gestiona una biblioteca comn a
dos o ms proyectos? La respuesta es sencilla: si es compartido pasa a disponer de su propio repositorio.
Antes de que las manos lleguen a la cabeza y se inicien los gritos y la quema:
Si lo utilizan varios proyectos es ms que probable que tenga entidad suficiente para ser un proyecto per se.
Se puede aadir utilizando referencias externas, por lo que el funcionamiento es completamente transparente
en cualquier proyecto. Adems, se simplifica su inclusin en cualquier otro futuro proyecto que lo precise.
Se puede definir polticas especiales adaptadas a la biblioteca, establecer un sistema de validacin
automtica.
Agrupando las zonas comunes (ms o menos relacionadas) de varios proyectos se crear la biblioteca
reutilizable para toda la organizacin sin grandes esfuerzos. Esta biblioteca crecer segn las necesidades y
con el esfuerzo de de todos.
Hasta aqu se han visto las caractersticas de SVN, la estructura general de los repositorios que se
recomienda utilizar, as como la posibilidad de definir un repositorio por proyectos o varios proyectos en un
repositorio. Ahora bien cmo instalar y configurar SVN para automatizar la gestin de la configuracin?
La respuesta a esta interrogante se describe en el siguiente epgrafe


Leer ms: http://www.monografias.com/trabajos78/implementacion-herramienta-gestion-configuracion-
subversion/implementacion-herramienta-gestion-configuracion-subversion2.shtml#ixzz30wP46C8m


Leer ms: http://www.monografias.com/trabajos78/implementacion-herramienta-gestion-configuracion-
subversion/implementacion-herramienta-gestion-configuracion-subversion.shtml#ixzz30wMXwWEG
Control de Configuracin
Continuamos hoy la serie de artculos dedicados a algunas de las
contribuciones del programa espacial a la gestin de proyectos, hablando sobre el Control de
Configuracin o Gestin de la Configuracin.

El control de configuracin, hoy habitualmente entendido como una disciplina ms o menos
independiente dentro de los equipos de ingeniera, con su propio equipo de tcnicos, es el
encargado de asegurar la configuracin de un determinado producto a todo lo largo de su vida.

Qu significa esto? Pues, dicho de forma sencilla, que tengamos controlada en todo momento la
configuracin interna de cualquier producto que haya salido de nuestra lnea de produccin,
independientemente de los cambios de diseo o mejoras implementadas a lo largo de la vida del
proyecto. Gracias al control de configuracin podemos saber cmo era exactamente el producto
que vendimos a determinado cliente hace 5 aos, que probablemente no sea idntico al que sali
de nuestra fbrica ayer. De esta forma podemos realizar un adecuado mantenimiento entregando
los repuestos adecuados en todo momento, y nos permite tambin, en caso de avera o accidente,
poder investigarlo con efectividad, al conocer exactamente la arquitectura interna de ese
determinado producto.


Dicho as, la cosa parece simple, pero en la realidad no lo es tanto. Y es que si pensamos en
productos tan complejos como un avin o un vehculo espacial, por ejemplo, constituidos por
millones de piezas diferentes y con lneas de produccin que a menudo se extienden a lo largo de
dcadas, el nmero de cambios implementados entre diferentes artculos salidos de la lnea de
produccin puede fcilmente contarse por millares. Y muy a menudo son cambios invisibles para el
cliente final, pero importantes a la hora de realizar el mantenimiento o, como decimos, de investigar
un accidente, por ejemplo.

Los cambios pueden ser de muy diferente tipo. Estn los cambios de versin, por ejemplo, estos
son los ms evidentes, donde el producto final s muestra una determinada diferencia, por pequea
que sea, con respecto a otros productos similares. Pero a menudo existen cambios que no
modifican la versin, por no variar el aspecto o prestaciones del producto final, y tratarse por tanto
de cambios indiferentes para el comprador. Por ejemplo, el cambio de un determinado tratamiento
de proteccin sobre una pieza porque el que se aplicaba hasta entonces ha sido prohibido por
cuestiones medioambientales (esto est sucediendo mucho ltimamente); o un cambio de material
en una pieza por otro de similares caractersticas, pero diferente. O una mejora en el diseo de una
pieza interna para hacerla ms econmica de fabricar, ms fcil de montar, ms ligera o menos
propensa a los fallos En fin, las razones de los cambios pueden ser, y son, de mltiple
naturaleza, pero os aseguro que los cambios en este tipo de productos son constantes, continuos a
lo largo de toda la vida del proyecto. Una vez que diseas un producto de esta complejidad,
puedes estar seguro de que tendrs que mantener activo un equipo de diseo hasta el mismo da
en que se decida cerrar la lnea de produccin, slo para implementar cambios da tras da.

La necesidad de mantener el control de los cambios y el perfecto conocimiento de la configuracin
de cada producto es evidente en algunos casos, pero quizs no tanto en otros. Si cambiamos el
diseo interno de una zona o de un conjunto de piezas, es evidente que tenemos que saber cules
eran exactamente las piezas que montaba determinado producto, para poder suministrar un
repuesto adecuado si es necesario. Tambin debemos poder examinar rpidamente los planos y
los documentos de clculo de aquel producto en concreto, por ejemplo para examinar si un
determinado dao sufrido en servicio es admisible o necesita reparacin o reemplazo.

Pero en otros casos, la necesidad de conocer en detalle la configuracin tiene un motivo distinto.
Supongamos, por ejemplo, que realizamos un cambio aparentemente indiferente, como cambiar un
anodizado crmico en una pieza de aluminio (proteccin anticorrosin) por un anodizado tartrico,
por razones medioambientales (todos los tratamientos con cromo estn siendo prohibidos en
buena parte del mundo). En principio, el cambio puede parecer indiferente, y si la pieza no cambia,
a efectos de recambios podra darnos igual, y podramos reemplazar una pieza antigua con
anodizado crmico por una nueva con anodizado tartrico. Pero supongamos que dentro de 10
aos descubrimos que el anodizado tartrico produce una reaccin qumica con el oxgeno del aire
a las 5 de la tarde de los das 25 de abril de ao bisiesto en los que llueva y salga el arco iris, y que
eso produce la desintegracin inmediata de la pieza (cambiad la chorrada por cualquier
descubrimiento imprevisto que afecte a la seguridad, y que fuera desconocido hasta entonces).
Esto lo descubrimos despus de investigar un accidente en el que un avin que llevaba una pieza
crtica con anodizado tartrico tuvo la mala suerte de volar a las 5 de la tarde de un 25 de abril de
ao bisiesto en una zona donde haba salido el arco iris, y se estrell. Tras la investigacin, se
decide sustituir todas las piezas con anodizado tartrico que equipen toda la flota mundial de
aviones. Y para eso, tenemos que saber exactamente qu aviones equipan ese tipo de piezas, y
dnde

A qu obliga esto? Primero, a conservar absolutamente toda la documentacin (planos,
documentos de clculo estructural, certificados de los materiales empleados, etc) de todos y cada
uno de los productos que salen por la puerta de nuestra fbrica. Cada versin del producto,
aunque slo se cambie un tornillo, debe contar con su propio juego de documentacin. Esto obliga
a reidentificar los productos, a que cada uno tenga una identificacin propia; hay que cambiar el
nmero identificativo de la pieza, por ejemplo, y necesitamos una trazabilidad que nos muestre
rpidamente qu productos incorporan esa pieza determinada, etc.

Esto obliga no slo a una continua edicin de nueva documentacin (el trabajo de modificaciones
en esta fase es un 10% de modificacin tcnica, y un 90% de burocracia para generar nueva
documentacin), sino a mantener una detallada base de datos que nos permita controlar todo este
maremgnum. Pues bien, el mantenimiento de dicha base de datos, la generacin de los
procedimientos (normas) que aseguren la correcta trazabilidad de los productos, etc, es decir, todo
lo que podramos considerar la gestin que rodea a estas actividades, es la misin del control de
configuracin.

Bueno, menuda introduccin S, ya s, entris aqu esperando leer sobre cohetes y astronautas
y robots en Marte, y os doy la chapa con esto, pero as los jovencitos no os llevaris sorpresas si
alguno decide meterse a ingeniero pensando en disear cohetes y luego se encuentra manejando
papeles el 70% de su tiempo ;-)

Bien, al grano: cundo y cmo naci esto del control de configuracin, tal y como lo conocemos
hoy en da? Pues la idea debi empezar a gestarse ms o menos tras el final de la Segunda
Guerra Mundial, y el primer proyecto en el que se implant esta tcnica fue para el desarrollo de
uno de los primeros motores a reaccin para la Fuerza Area de los Estados Unidos, durante los
aos 50. Despus, la metodologa se fue desarrollando hasta editarse la primera norma oficial por
parte de la USAF en 1962.

Claramente, la necesidad haba nacido en el campo de la aviacin, con el desarrollo de aeronaves
y motores cada vez ms complejos, que hacan evidente la necesidad de una gestin de este tipo.
Pero con lo que el Control de Configuracin lleg a su culmen fue con el proyecto Apollo, tambin
desarrollado durante los aos 60. Podemos decir que el Apollo constituy la prueba de fuego de
esta disciplina recin nacida.

Como sabis, el Apollo sigue siendo a da de hoy el mayor proyecto de ingeniera de toda la
historia. El desarrollo de los cohetes y las naves encargados de llevar al hombre hasta la Luna
implicaron a millones de personas, que desarrollaron productos compuestos a su vez por miles de
millones de elementos diferentes. Y, como siempre, sometidos a constantes cambios.

Si bien el Control de Configuracin ya exista como tal, el proyecto Apollo exigi el
perfeccionamiento de sus metodologas, pudindose considerar por tanto como los orgenes de las
modernas tcnicas de control de configuracin. En realidad, el Apollo fue tan extremadamente
complejo que buena parte de las herramientas de planificacin y gestin de proyectos que usamos
en la actualidad tienen sus orgenes remotos relacionados de alguna forma con el programa que
llev al hombre a la Luna. Ya se sabe que la necesidad agudiza el ingenio, y desde luego el Apollo
gener muchsimas necesidades de gestin de todo tipo.

Hoy en da, el Control de Configuracin ha extendido sus fronteras. Si en un principio naci en un
contexto aeronutico derivndose rpidamente al rea espacial, tampoco tard en contagiar a la
incipiente industria de la informtica. Ya en los aos 60 los primeros desarrollos de software
empezaron a utilizar tcnicas de control de configuracin, y probablemente sea en la actualidad el
rea que ms extensivo uso realiza de estas tcnicas. Y es que no slo el software y la informtica
en general estn tambin en continuo cambio, sino que probablemente sean el rea que ms
rpidamente evoluciona en nuestra sociedad actual. Para ellos tambin, el control de configuracin
es una clara necesidad.


La aeronutica andaluza ha experimentado en los ltimos aos un
significativo incremento en el nmero de empresas dedicadas a la
prestacin de servicios de calidad para las grandes compaas del sector,
como consecuencia de la apuesta por la diversificacin hacia reas menos
desarrolladas o poco presentes en Andaluca. Un rea que presenta un
amplio abanico de actividades, desde procesos de auditora y consultora,
hasta calibracin, verificacin y ensayos tcnicos y de sistemas, que han
creado interesantes expectativas de negocio para diferentes firmas
andaluzas pero que podra sufrir un cambio radical ante la poltica de
reduccin de proveedores de los contratistas internacionales.

La apuesta por la diversificacin de productos y servicios que el cluster aeroespacial andaluz est
potenciando como uno de los retos para lograr una mayor competitividad del sector y optar a
contratos y proyectos de envergadura a nivel internacional no slo ha comenzado reflejarse en la
creciente participacin en los grandes programas aeronuticos o en una mayor internacionalizacin
de las empresas andaluzas, sino tambin en otras cuestiones como la especializacin en reas
tradicionalmente menos desarrolladas o poco presentes en Andaluca. Es el caso de subsectores
como la ingeniera, la electrnica, los sistemas no tripulados o los servicios relacionados con el
mbito de la calidad, aspectos en los que el sector aeronutico ha ido creciendo en los ltimos
aos y en los que ha visto posibilidades de aportar mayor valor aadido a sus trabajos y productos.
Dentro de estas reas destaca el incremento de actividad que se viene produciendo en est ltima,
la de la calidad, en la que la aeronutica andaluza ha experimentado un significativo crecimiento
tambin en cuanto al nmero de empresas dedicadas a la prestacin de este tipo de servicios para
las grandes compaas del sector. Un rea que cuenta con un amplio abanico de actividades
especficas desde procesos de auditora y consultora de calidad, hasta calibracin, verificacin y
ensayos tcnicos y de sistemas-, y que ha creado interesantes expectativas de negocio para
diferentes firmas andaluzas, dado el potencial que presenta. No obstante, esta situacin podra
sufrir un cambio radical ante la poltica de reduccin de proveedores que vienen implantando los
contratistas internacionales, como ya vie ne sucediendo, por ejemplo, en reas como la ingeniera,
y con la que las tractoras pretenden buscar socios de mayor dimensin industrial y financiera que
puedan afrontar grandes cargas de trabajo y compartir los riesgos del proyecto.
En este campo pueden incluirse empresas como Grupo Prescal, Mave Aeronutica o Global
Quality, especializadas en ingeniera de calidad, consultora, auditora inspeccin y control de
procesos; y otras como TEAMS, Canagrosa, Simetrycal o Titania, ms centradas en la verificacin
de piezas y componentes, calibracin, metrologa y ensayos de sistemas y equipos, un subsector
en el que los grandes constructores de aviones estn apostando por un mayor nivel de
subcontratacin.
Dentro del campo de los servicios de calidad en Andaluca destacan
empresas como Prescal, Mave, Global Quality, TEAMS, Canagrosa,
Simetrycal, MCI o Titania"
Una de las firmas destacadas en el mbito de la calidad aeronutica em Andaluca es la gaditana
Mave Aeronutica, empresa con ms de 10 aos de experiencia en la industria aeronutica, y que
desarrolla servicios directos para clientes como Airbus Military, Airbus y Alestis. Con ms de 150
profesionales especializados, las actividades de Mave se centran en la calidad de utillaje y medios
de produccin (mantenimiento), ingeniera de calidad e inspeccin. Consciente de la importancia
que est tomando la estrategia de reduccin de proveedores de EADS, la empresa dio a finales de
2011 un paso adelante para afianzar su posicionamiento tras alcanzar un acuerdo de colaboracin
con el Grupo CT Ingenieros, especializado en servicios de ingeniera de diseo y fabricacin, y con
el que pretende aunar fuerzas para ofertar conjuntamente proyectos al fabricante europeo.
Grupo Prescal es otra de las empresas andaluzas de este sector. La firma ha consolidado su
crecimiento hasta alcanzar los 4 millones de euros y una plantilla de 42 empleados en su divisin
aeronutica a cierre de 2011, y ha emprendido con xito su proceso de expansin internacional,
abriendo delegaciones en Chile, Brasil, Polonia, Reino Unido y Emiratos rabes Unidos. Para
lograr este objetivo, la compaa ha centrado su actividad en la consolidacin y ampliacin de su
cartera de servicios, en la que se incluye la gestin o ingeniera de calidad (procesos), control
(productos), ensayos no destructivos, planificaciones y control de configuracin, montajes,
mecnicos, estructurales y elctricos; soporte comercial, tcnico y logstico, as como formacin,
consultora y prevencin de riesgos laborales.
Dentro de este segmento tambin ha irrumpido la firma Global Q (Global Quality Engineering
Services), surgida de la fusin entre Quality Engineering Services e Ingeniera de Calidad General,
dos empresas con amplia experiencia en el sector y cuyo fin es ofrecer un servicio tcnico
especializado en seguimiento de productos y proveedores, gestin de medios productivos,
preparacin y actualizacin de documentacin tcnica, y consultora de gestin de cambios y
configuracin de producto. La empresa cuenta con oficinas en Sevilla, Getafe (Madrid) y Vitoria, los
tres principales focos aeronuticos a nivel nacional, y busca ir ampliando su mercado a travs de
las grandes compaas y Tier One en Espaa, para los que ya trabaja.

A esta actividad en servicios de calidad aeronutica hay que sumar la referente a calibracin y
metrologa, verificacin de piezas, ensayos de materiales y sistemas (presin, fatiga, etc.) e incluso
pruebas en vuelo, un rea que se encuentra en pleno auge a tenor de las nuevas empresas que
han surgido en los ltimos aos en Andaluca. Dentro del apartado de calibracin y metrologa
destacan firmas como Canagrosa, con una destacada experiencia en el sector, y cuyos servicios
contemplan desde controles de mecanizados, tratamientos superficiales, soporte para montaje de
aeroestructuras, FAL y lnea en vuelo, hasta logstica y postventa aeronutica, consultora de
procesos, sistemas de calidad y montaje de lneas de produccin y proyectos de investigacin. O
jvenes empresas como Simetrycal (Servicos Integrales de Metrologa y Calibracin), firma de de
base tecnolgica surgida como spin off de la Universidad de Sevilla en 2010 como complemento y
extensin de las actividades del Centro Andaluz de Metrologa (CAM), con una dilatada experiencia
en proyectos con Airbus Military desde hace ms de una dcada.
Tambin se enmarcan aqu otras entidades como Veiasa (Verificaciones Industriales de
Andaluca), empresa pblica de la Consejera de Economa, Innovacin, Ciencia y Empleo que
desarrolla trabajos de inspeccin y control metrolgico para las distintas reglamentaciones
industriales, entre ellas la aeronutica; o MCI (Laboratorio de Metrologa y Calibracin Industrial),
compaa que cuenta con una delegacin en Andaluca desde 2006 y que opera desde 2010 en
Aerpolis para los subcontratistas ms destacadas del sector internacional (Airbus, Airbus Military,
Boeing, Embraer, etc.)
Asimismo, es especialmente relevante el papel que estn jugando otras empresas dedicadas de
manera ms ntegra a la caracterizacin de materiales, realizacin de ensayos mecnicos y
estructurales e inspecciones no destructivas, como es el caso de la empresa TEAMS (Testing and
Engineering of Aeronautical Materials and Structures), tambin spin-off de la Universidad de Sevilla
y que en apenas seis aos se ha convertido en todo un referente en este campo, gracias a su
designacin como primer laboratorio espaol y cuarto a nivel europeo que cuenta con la distincin
de Tier One en Materiales y Procesos por Airbus, y a la adjudicacin del programa de ensayos
sobre materiales, componentes y sistemas de la belly fairing y del cono de cola del avin A350.
Igualmente hay que destacar a la firma Titania, Ensayos y Proyectos Industriales, surgida a partir
de las actividades del Laboratorio de Ensayos, Corrosin y Proteccin de la Universidad de Cdiz,
que tambin ha comenzado a desarrollar actuaciones para empresas del sector aeronutico y que
centra su lnea de negocio en el control de calidad de materiales, asistencias tcnicas y desarrollo
de proyectos de I+D de aplicacin industrial. A todas ellas hay que sumar a la compaa Applus,
multinacional lder en las reas de ensayo, consultora, inspeccin y certificacin tecnolgica que
acaba de aterrizar en Andaluca tras abrir nuevas oficinas en Aerpolis. Una incorporacin que
refleja las oportunidades de negocio que cada vez ms estn generando los servicios de calidad y
la posicin estratgica que ya ocupa el sector andaluz en general en el panorama europeo e
internacional.