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