Bilioteca de infraestructura de tecnología de información (ITIL) Gestión de versiones VERSIONES.pdf

ITIL: GESTION DE VERSIONES

Investigador: Mara Eugenia Bravo Campoverde Pagina 1

CAPITULO I

INTRODUCCIN A ITIL

1.1 Definicin de ITIL

ITIL son las siglas de una metodologa desarrollada a finales de los aos 80s

por iniciativa del gobierno del Reino Unido, especficamente por la OGC u

Oficina Gubernativa de Comercio Britnica (Office of Goverment Comerce). Las

siglas de ITIL significan (Information Technology Infrastructure Library) o

Librera de Infraestructura de Tecnologas de Informacin.

Esta metodologa es la aproximacin ms globalmente aceptada para la

gestin de servicios de Tecnologas de Informacin en todo el mundo, ya que

es una recopilacin de las mejores prcticas tanto del sector pblico como del

sector privado. Estas mejores prcticas de dan en base a toda la experiencia

adquirida con el tiempo en determinada actividad, y son soportadas bajo

esquemas organizacionales complejos, pero a su vez bien definidos, y que se

apoyan en herramientas de evaluacin e implementacin.

ITIL brinda una descripcin detallada de un nmero de prcticas importantes en

IT, a travs de una amplia lista de verificacin, tareas, procedimientos y

responsabilidades que pueden adaptarse a cualquier organizacin IT. En

algunos casos hasta se han definido las prcticas como procesos que cubren

las actividades ms importantes de las organizaciones de servicio IT. La vasta

cantidad de temas cubiertos por las publicaciones transforma a la ITIL en un

elemento de referencia til para fijar nuevos objetivos de mejora para la

organizacin IT. La organizacin puede crecer y madurar con ellos.

En base a ITIL se han desarrollado varios sistemas para la Administracin de

Servicio IT, generalmente organizaciones del negocio. Los ejemplos incluyen

Hewlett & Packard (HP ITSM modelo de referencia), IBM (IT Modelo de

Proceso), Microsoft (MOF) y muchos otros. sta es una de las razones por las

que ITIL se ha convertido en el estndar de facto para describir varios procesos



fundamentales de la Administracin de Servicio IT. Esta adopcin y adaptacin

de ITIL refleja la filosofa de ITIL, y es un desarrollo bienvenido ya que la ITIL

se ha transformado en el tan necesario orden imprescindible para el actual

medio heterogneo y dividido de IT.

ITIL fue desarrollada al reconocer que las organizaciones dependen cada vez

ms de IT para alcanzar sus objetivos corporativos. Esta dependencia en

aumento ha dado como resultado una necesidad creciente de servicios IT de

calidad que se correspondan con los objetivos del negocio, y que satisfaga los

requisitos y las expectativas del cliente.

ITIL ofrece un marco comn para todas las actividades del departamento IT,

como parte de la provisin de servicios, basado en la infraestructura IT. Estas

actividades se dividen en procesos, que dan un marco eficaz para lograr una

Administracin de Servicio IT ms madura. Cada uno de estos procesos cubre

una o ms tareas del departamento IT, tal como desarrollo de servicio,

administracin de infraestructura, y provisin y soporte de los servicios. Este

planteo del proceso permite describir las mejores prcticas de la Administracin

de Servicio IT independientemente de la estructura de organizacin real de la

entidad.

1.2 El objetivo de usar ITIL en Managed Services

ITIL como metodologa propone el establecimiento de estndares que nos

ayuden en el control, operacin y administracin de los recursos (ya sean

propios o de los clientes). Plantea hacer una revisin y reestructuracin de los

procesos existentes en caso de que estos lo necesiten (si el nivel de eficiencia

es bajo o que haya una forma ms eficiente de hacer las cosas), lo que nos

lleva a una mejora continua.

Otra de las cosas que propone es que para cada actividad que se realice se

debe de hacer la documentacin pertinente, ya que esta puede ser de gran

utilidad para otros miembros del rea, adems de que quedan asentados todos



los movimientos realizados, permitiendo que toda la gente est al tanto de los

cambios y no se tome a nadie por sorpresa.

En la documentacin se pone la fecha en la que se hace el cambio, una breve

descripcin de los cambios que se hicieron, quien fue la persona que hizo el

cambio, as como quien es el que autorizo el cambio, para que as se lleve todo

un seguimiento de lo que pasa en el entorno. Esto es ms que nada como

mtodo con el que se puede establecer cierto control en el sistema de cambios,

y as siempre va a haber un responsable y se van a decir los procedimientos y

cambios efectuados.

Las ventajas de ITIL para los clientes y usuarios

Mejora la comunicacin con los clientes y usuarios finales a travs de los

diversos puntos de contacto acordados.

Los servicios se detallan en lenguaje del cliente y con ms detalles.

Se maneja mejor la calidad y los costos de los servicios.

La entrega de servicios se enfoca mas al cliente, mejorando con ello la

calidad de los mismos y relacin entre el cliente y el departamento de IT.

Una mayor flexibilidad y adaptabilidad de los servicios.

Ventajas de ITIL para TI

La organizacin TI desarrolla una estructura ms clara, se vuelve ms eficaz,

y se centra ms en los objetivos de la organizacin.

La administracin tiene un mayor control, se estandarizan e identifican los

procedimientos, y los cambios resultan ms fciles de manejar.

La estructura de procesos en IT proporciona un marco para concretar de

manera ms adecuada los servicios de outsourcing.



A travs de las mejores prcticas de ITIL se apoya al cambio en la cultura de

TI y su orientacin hacia el servicio, y se facilita la introduccin de un sistema

de administracin de calidad.

ITIL proporciona un marco de referencia uniforme para la comunicacin

interna y con proveedores.

Desventajas

Tiempo y esfuerzo necesario para su implementacin.

Que no se d el cambio en la cultura de las reas involucradas.

Que no se vea reflejada una mejora, por falta de entendimiento sobre

procesos, indicadores y como pueden ser controlados.

Que el personal no se involucre y se comprometa.

La mejora del servicio y la reduccin de costos puede no ser visible.

Que la inversin en herramientas de soporte sea escasa. Los procesos

podrn parecer intiles y no se alcancen las mejoras en los servicios.

La Figura 1 indica el manejo de servicios que lleva el negocio a travs de la

Tecnologa ITIL.



Figura 1: ITIL en Managed Services

1.3 Concepto de soluciones para ITIL desde el punto de vista de negocio

Segn la Figura 2 vemos como aparentemente tenemos segmentos del

negocio aislados, pero en realidad todos tienen algo que ver para la obtencin

de las soluciones. Por ejemplo la prestacin de servicios muchas veces no

sera posible sin la gestin de infraestructura, asimismo las perspectivas del

negocio no se daran sin la prestacin de servicio y los servicios no serian

posibles sin un soporte al servicio. Y el punto de interaccin que se da entre

estos segmentos del negocio es la bsqueda de soluciones, donde lo que se

busca es que las perspectivas del negocio estn soportadas en base a la

prestacin de servicios; la prestacin de servicios requiere que se le de un

soporte al servicio para que este siempre disponible, la disponibilidad la

podemos lograr mediante una gestin de la infraestructura y en lugar de tener

al centro las soluciones vamos a tener a los clientes satisfechos.



Las reas de un negocio no pueden estar aisladas unas de otras. El punto de

interaccin que se da entre las diferentes reas de un negocio es la bsqueda

de soluciones, donde lo que se pretende es que las perspectivas del negocio

estn soportadas entre s por medio del sistema.1

Figura2: Soluciones para ITIL desde el punto de vista de negocio

1.4 Certificacin

Los particulares pueden conseguir varias certificaciones oficiales ITIL. Los

estndares de calificacin ITIL son gestionados por la ITIL Certification

Management Board (ICMB) que agrupa a la OGC, a itSMF International y a los

dos Institutos Examinadores existentes: EXIN (con sede en los Pases Bajos) e

ISEB (con sede en el Reino Unido).

Existen tres niveles de certificacin ITIL para profesionales:

1. Foundation Certificate (Certificado Bsico): acredita un conocimiento

bsico de ITIL en gestin de servicios de tecnologas de la informacin y

1 http://www.monografias.com/trabajos31/metodologia-itil/metodologia-itil.shtml



la comprensin de la terminologa propia de ITIL. Est destinado a

aquellas personas que deseen conocer las buenas prcticas

especificadas en ITIL.

2. Practitioner's Certificate (Certificado de Responsable): destinado a

quienes tienen responsabilidad en el diseo de procesos de

administracin de departamentos de tecnologas de la informacin y en

la planificacin de las actividades asociadas a los procesos.

3. Manager's Certificate (Certificado de Director): garantiza que quien lo

posee dispone de profundos conocimientos en todas las materias

relacionadas con la administracin de departamentos de tecnologas de

la informacin, y lo habilita para dirigir la implantacin de soluciones

basadas en ITIL.

No es posible certificar una organizacin o sistema de gestin como conforme

a ITIL, pero una organizacin que haya implementado las guas de ITIL sobre

Gestin de los Servicios de TI puede lograr certificarse bajo la ISO/IEC 20000.2

La versin 3 de ITIL, que apareci en junio de 2007, cambi ligeramente el

esquema de Certificaciones, existiendo certificaciones puentes, se definen 3

niveles:

1. Basic Level (Equivalente a ITIL Foundation en v2)

2. Management and Capability Level (Equivalente a los niveles Practitioner

y Manager en ITIL v2)

3. Advanced Level (nuevo en v3)

1.5 Historia y precursores de ITIL

Lo que actualmente se conoce como ITIL versin 1, desarrollada bajo el

auspicio de la CCTA, se titul Government Information Technology

Infrastructure Method (Mtodo de Infraestructura de la Tecnologa de 2 http://es.wikipedia.org/wiki/Information_Technology_Infrastructure_Library



Informacin del Gobierno, GITM) y durante varios aos termin expandindose

hasta unos 31 libros dentro de un proyecto inicialmente dirigido por Peter

Skinner y John Stewart. Las publicaciones fueron retituladas principalmente

como resultado del deseo (por Roy Dibble de la CCTA) de que fueran vistas

como una gua y no como un mtodo formal, y como resultado del creciente

inters que haba fuera del gobierno britnico.

Muchos de los conceptos principales de gestin de servicios no surgieron

dentro del proyecto inicial de la CCTA para desarrollar ITIL. IBM afirma que sus

Yellow Books (A Management System for the Information Business, Un

sistema de gestin para el negocio de la informacin)[4] [5] fueron precursores

claves. Segn IBM:

A principios de los aos 1980, IBM document los conceptos originales de

Gestin de Sistemas en una serie de cuatro volmenes titulada A Management

System for Information Systems (sic). Estos ampliamente aceptados yellow

books [...] fueron aportaciones claves para el conjunto originales de libros de

ITIL.

Otras publicaciones de IBM y comentarios de los autores de ITIL aclaran que

los yellow books fueron cruciales para el desarrollo del Servicio de Soporte

pero que el volumen de Entrega de Servicios no tom prestado de ellos hasta

tales extremos.

1.6 Crticas a ITIL

ITIL ha recibido crticas de varios frentes. Entre ellas:

El hecho de que muchos defensores de ITIL parecen creer que es un

marco holstico y completo para el gobierno de TI.

Su tendencia a convertirla en una religin.

Como seala Jan van Bon (autor y editor de muchas publicaciones de Gestin

de Servicios de TI).



Hay mucha confusin sobre ITIL, procedente de todo tipo de malentendidos

sobre su naturaleza. ITIL, como afirma la OGC, es un conjunto de buenas

prcticas. La OGC no afirma que dichas mejoras prcticas describan procesos

puros, ni tampoco que ITIL sea un marco diseado como un modelo coherente.

Eso es lo que la mayora de sus usuarios hacen de ella, probablemente porque

tienen una gran necesidad de dicho modelo. 3

El columnista CIO Magazine Dean Meyer tambin ha expuesto algunos puntos

de vista cautelosos sobre ITIL, incluyendo cinco trampas tpicas tales como

convertirse en esclavo de definiciones desactualizadas y dejar que ITIL se

convierta en religin. Como Meyer seala, ITIL no describe el abanico

completo de procesos necesarios para ser lderes. Se centra en [...] gestionar

servicios actuales.4

La calidad de los volmenes de la biblioteca se considera desigual. Por

ejemplo, Van Herwaarden y Grift sealan que la consistencia que

caracterizaba los procesos de soporte al servicio [...] se pierde en gran medida

en los libros de entrega de servicio.5

1.7 Forma de uso de ITIL en Managed Services

ITIL postula que el servicio de soporte, la administracin y la operacin se

realiza a travs de cinco procesos:

1. Manejo de Incidentes

2. Manejo de problemas

3. Manejo de configuraciones

4. Manejo de cambios y

5. Manejo de entregas

3 Jan van Bon (autor y editor de muchas publicaciones de Gestin de Servicios de TI).

4 CIO Magazine Dean Meyer

5 Van Herwaarden y Grift



1.7.1 PROCESO DE MANEJO DE INCIDENTES

Su objetivo primordial es restablecer el servicio lo ms rpido posible para

evitar que el cliente se vea afectado, esto se hace con la finalidad de que se

minimicen los efectos de la operacin. Se dice que el proveedor de debe de

encargar de que el cliente no debe percibir todas aquellas pequeas o grandes

fallas que llegue a presentar el sistema. A este concepto se le llama

disponibilidad (que el usuario pueda tener acceso al servicio y que nunca se

vea interrumpido).

Para este proceso se tiene un diagrama que en cada una de sus fases maneja

cuatro pasos bsicos que son: propiedad, monitoreo, manejo de secuencias y

comunicacin.

En el proceso de manejo de incidentes vemos en la Figura 3 que se da como

primera etapa la deteccin del incidente (es cuando el sistema presenta alguna

anomala o falla, y que esto se puede traducir en un error en el sistema o que el

usuario no puede hacer algo y recurre a pedir ayuda); ya que lo tenemos

identificado se hace una clasificacin del incidente (vemos si el error que se

presenta es conocido o si nunca se ha presentado) y de la mano va el soporte

inicial (es el punto en el que el cliente llega a la mesa de servicio a solicitar

ayuda, porque no sabe o no puede hacer algo); en caso de que el incidente sea

conocido se hace el procedimiento de solicitud de servicio (se ejecutan los

pasos a seguir segn el manual de procedimientos para poder llegar a la

solucin de una forma viable y eficiente); una vez que ya que se la dio una

solucin al incidente por medio del manual de procedimientos se recurre a la

documentacin y contabilizacin del incidente, para ver qu tanta incidencia

tiene este caso; finalmente se hace una evaluacin para ver si efectivamente

se resolvi el incidente de forma satisfactoria y en supuesto de ser afirmativa

se cierra el incidente y el otro supuesto seria que de la solucin que se planteo

no es lo suficientemente eficiente o acertada para que resuelva el problema y

se recurre a hacer una investigacin y un diagnostico de la situacin para ver

cmo es que se puede atacar el problema de frente y resolverlo; una vez que



se tiene todo un contexto analizado se recurre a la ejecucin de la propuesta

de solucin del incidente y se hace un estudio para ver si el incidente es

recuperable o si es caso perdido (la mayora de los casos son recuperables,

peo cuando el nivel de dao es muy fuerte, se da el caso de que se d por

perdido); y finamente se cierra el incidente y esta solucin se documenta en

una base de datos a la que se le llama base del conocimiento o Knowledge

Data Base (aqu vienen documentadas todas las soluciones, y se establecen

los pasos a seguir para que se hagan de forma eficiente) para que al momento

de volverse a presentar el incidente ya va a estar documentado y esto hace

que sea ms fcil, rpida y eficiente su resolucin.6

Figura 3: Proceso de manejo de incidentes

1.7.2 PROCESO DE MANEJO DE PROBLEMAS

El Objetivo de este proceso es prevenir y reducir al mximo los incidentes, y

esto nos lleva a una reduccin en el nivel de incidencia. Por otro lado nos

6 http://www.monografias.com/trabajos31/metodologia-itil/metodologia-itil.shtml



ayuda a proporcionar soluciones rpidas y efectivas para asegurar el uso

estructurado de recursos.

En este proceso lo que se busca es que se pueda tener pleno control del

problema, esto se logra dndole un seguimiento y un monitoreo al problema.

La figura 4 de este proceso es muy particular, ya que se maneja en dos fases:

la primera est relacionada con lo que es el control del problema y la segunda

es con el control del error.7

En lo que respecta a la fase de control del problema: primero se tiene que

identificar el problema en base a alguna sintomatologa; ya que tenemos este

antecedente, pasamos a la clasificacin de los problemas (en este proceso al

igual que en el proceso de manejo de incidentes tenemos que ver si es un

problema conocido), en caso de ser conocido, se recurre al procedimiento de

solicitud de servicio, donde se van a aplicar las soluciones de acuerdo a como

estn en el manual de procedimientos; y en caso de no ser conocido se tendra

que hacer una fase de investigacin para ver qu es lo que genera el problema

y ms tarde hacer un diagnostico; ya que tenemos un diagnstico tenemos que

hacer un RFC (Request For Change o Solicitud de Cambio),

Esta solicitud de cambio implica que se va a tener que implementar la solucin

y finalmente se va a hacer una evaluacin para ver si se resolvi el problema

de raz. En caso de que si se funcione esta solucin se pasa a la

documentacin.

Con lo que respecta a la segunda fase del modelo, el control del error se hace

por medio de una identificacin del error en general, posteriormente se hace

una especie de registro, y este va a servir para clasificar el error; ya que se

tiene una clasificacin y se recurre a una evaluacin de que tanto dao genero

o puede llegar a generar el error, esto con la finalidad de cuantificar los

desperfectos que podra llegar a causar en caso de que el error prevalezca y

no se solucione; posteriormente se hace la resolucin o correccin del error

7 http://www.monografias.com/trabajos31/metodologia-itil/metodologia-itil.shtml#proceso



(este puede deberse a varios aspectos: configuraciones, falta de seguridad,

inconsistencia de datos, etc.); y este modelo tiene una fase muy difcil, que es

determinar que problemas estn asociados o como es que al momento de

cambiar algo el sistema, se va a cambiar de forma uniforme y no se va a

alterar, y que presente inconsistencias. Por ejemplo que es lo que pasara si

cambio algunos de los datos en la configuracin del sistema, se tendra que

afectar el sistema de manera uniforme para que siga en equilibrio y no est

cambiado en algunas partes y en otras que se quede como estaba antes.

Figura 4: Proceso de manejo de problemas

1.7.3 PROCESO DE MANEJO DE CONFIGURACIONES

Su objetivo es proveer con informacin real y actualizada de lo que se tiene

configurado e instalado en cada sistema del cliente.

Este proceso es de los ms complejos como muestra la Figura 5, ya que se

mueve bajo cuatro vrtices que son: administracin de cambios, administracin



de liberaciones, administracin de configuraciones y la administracin de

procesos diversos.8

El nivel de complejidad de este modelo es alto, ya que influyen muchas

variables y muchas de ellas son dinmicas, entonces al cambiar una o varias

de ellas se afecta el sistema en general, lo que hace que sea muy difcil de

manipular. Aunque es lo ms parecido a la realidad, porque nuestro entorno es

dinmico y las decisiones de unos afectan a otros. Por ejemplo en lo que

respecta a la administracin de cambios vemos que se relaciona directamente

con la administracin de incidentes y de problemas, lo que conlleva una

planeacin, identificacin, control, seguimiento del status, verificacin y

auditoria de configuraciones, lo que hace que haya muchas variables.

En otro ejemplo la implementacin de cambios implica que se tiene que hacer

la liberacin y distribucin de nuevas versiones, esto de da por una fase de

planeacin, identificacin, control, revisin del status, verificacin y auditoria, y

puede depender de la administracin de las capacidades, ya que si no se

cuenta con el software o con el hardware esta fase no se podra llevar a cabo; y

as se hara con todos los niveles hasta llegar al cierre del control de cambios.




Figura 5: Proceso de manejo de configuraciones

1.7.4 PROCESO DE CONTROL DE CAMBIOS

El objetivo de este proceso es reducir los riesgos tanto tcnicos, econmicos y

de tiempo al momento de la realizacin de los cambios.

La Figura 6 al parecer es muy fcil de seguir, pero en realidad no lo es, ya que

entre etapa y etapa se da una fase de monitoreo para ver que no se han sufrido

desviaciones de los objetivos.9

Primero vemos que tenemos un registro y clasificacin del cambio que se tiene

que hacer, se pasa a la fase de monitoreo y planeacin, si el rendimiento es




satisfactorio se da la aprobacin del cambio, y en caso de que el rendimiento

sea malo se pasa a la fase de reingeniera hasta que el proceso funcione

adecuadamente, ya que se aprueban los cambio, se construyen prototipos o

modelos en los que se van a hacer las pruebas, se hacen las pruebas

pertinentes para ver las capacidades del sistema, ya que el proceso est

probado se da la autorizacin e implementacin; ya implementado se ve que no

se hayan tenido desviaciones y se ajusta a las necesidades actuales que

tambin se le considera como revisin post-implementacin.

Figura 6: Proceso de control de cambios

1.7.5 PROCESO DE MANEJO DE ENTREGAS

Su objetivo es planear y controlar exitosamente la instalacin de Software y

Hardware bajo tres ambientes: ambiente de desarrollo, ambiente de pruebas

controladas y ambiente real.

Este proceso tiene un diagrama que marca la transicin que se da de acuerdo

a los ambientes por los que se va dando la evolucin del proyecto.



En lo que respecta al ambiente de desarrollo vemos en la Figura 7 que se tiene

que hacer la liberacin de las polticas, la liberacin de la planeacin, el diseo

lgico de la infraestructura que se va a implementar y la adquisicin de

software y hardware estn entre los ambientes de desarrollo y de pruebas

controladas; ya que se requiere que ambos hagan pruebas sobre ellos; en el

ambiente de pruebas controladas vemos que se hace la construccin y

liberacin de las configuraciones (nivel lgico), se hacen las pruebas para

establecer los acuerdos de aceptacin; se da la aceptacin total de versiones y

de modelos, se arranca la planeacin y finalmente las pruebas y

comunicaciones; y en lo que es el ambiente real vemos que se da la

distribucin e instalacin. 10

En la etapa del ambiente real es la que se ve de forma ms concreta, ya que

muchas veces no tenemos idea de todo lo que pasa hasta antes de la

instalacin.

En el proceso de entrega del servicio es el punto en el que el usuario hace uno

del servicio y no sabe que detrs del servicio que est recibiendo hay un sin fin

de actividades y de decisiones que se tuvieron que tomar para que llegar a este

punto.

Este proceso es en el que ms cuidado debemos de poner, ya que en caso de

haber fallas, el primero en detectarlas o en percibirlas es el usuario, y eso nos

genera que el cliente este insatisfecho o molesto. Por lo general los usuarios no

saben que para que puedan hacer uso de los servicios, se paso por una fase

de planeacin, monitoreo, anlisis y por un sin fin de pruebas, con la intencin

de que en caso de que algo no funcione, se d en la fase de pruebas

controladas y no en la fase de pruebas en ambiente real, donde el mayor

afectado es el cliente.

10

http://www.monografias.com/trabajos31/metodologia-itil/metodologia-itil.shtml#proceso



Figura 7: Proceso de manejo de entregas



CAPITULO II

GESTION DE VERSIONES

2.1 Introduccin y Objetivos

La Gestin de Versiones es la encargada de la implementacin y control de

calidad de todo el software y hardware instalado en el entorno de produccin.

La Gestin de Versiones debe colaborar estrechamente con la Gestin de

Cambios y de Configuraciones para asegurar que toda la informacin relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

sta se halle correctamente actualizada y ofrezca una imagen real de la

configuracin de la infraestructura TI.

La Gestin de Versiones tambin debe mantener actualizada la Biblioteca de

Software Definitivo (DSL), donde se guardan copias de todo el software en

produccin, y el Depsito de Hardware Definitivo (DHS), donde se almacenan

piezas de repuesto y documentacin para la rpida reparacin de problemas de

hardware en el entorno de produccin.

Las interacciones y funcionalidades de la Gestin de Versiones se resumen

sucintamente en el siguiente interactivo:

Las complejas interrelaciones entre todos los elementos que componen una

infraestructura TI convierten en tarea delicada la implementacin de cualquier

cambio.

La Gestin de Cambios es la encargada de aprobar y supervisar todo el

proceso pero es tarea especfica de la Gestin de Versiones el disear, poner a

prueba e instalar en el entorno de produccin los cambios preestablecidos.

Todo ello requiere de una cuidadosa planificacin y coordinacin con el resto

de procesos asociados a la Gestin de Servicios TI.



Entre los principales objetivos de la Gestin de Versiones se incluyen:

Establecer una poltica de implementacin de nuevas versiones de

hardware y software.

Implementar las nuevas versiones de software y hardware en el entorno

de produccin tras su verificacin en un entorno realista de pruebas.

Garantizar que el proceso de cambio cumpla las especificaciones de la

RFC correspondiente.

Asegurar, en colaboracin con la Gestin de Cambios y

Configuraciones, que todos los cambios se ven correctamente reflejados

en la CMDB.

Archivar copias idnticas del software en produccin, as como de toda

su documentacin asociada, en la Biblioteca de Software Definitivo

(DSL).

Mantener actualizado el Depsito de Hardware Definitivo (DHS).

2.2 Beneficios y Dificultades

Los beneficios de una correcta Gestin de Versiones se resumen en:

El proceso de cambio se realiza sin deterioro de la calidad de servicio.

Las nuevas versiones cumplen los objetivos propuestos.

Se reduce el nmero de incidentes por incompatibilidades con otro

software o hardware instalado.

El proceso de pruebas asociado no slo permite asegurar la calidad del

software y hardware a instalar sino que tambin permite conocer la

opinin de los usuarios sobre la funcionalidad y usabilidad de las nuevas

versiones.

El correcto mantenimiento de la DSL impide que se pierdan (valiosas)

copias de los archivos fuente.

Se reduce el nmero de copias de software ilegales.

Control centralizado del software y hardware desplegado.



Proteccin contra virus y problemas asociados a versiones de software

incontroladas.

Las principales dificultades con las que topa la Gestin de Versiones son:

No existe una clara asignacin de responsabilidades y/o la organizacin

TI no acepta la figura dominante de la Gestin de Versiones en todo el

proceso de implementacin del cambio.

No se dispone de un entorno de pruebas adecuado en donde se puedan

testear de forma realista las nuevas versiones de software y hardware.

Hay resistencia en los diferentes departamentos a la centralizacin del

proceso de cambio. Es habitual que existan reticencias a adoptar

sistemas estandarizados en toda la organizacin, sobre todo cuando

sta no ha sido la poltica tradicional de la misma.

Se realizan cambios sin tener en cuenta a la Gestin de Versiones

argumentado que estos slo son responsabilidad de un determinado

grupo de trabajo o que su "urgencia" requera de ello.

Hay resistencias a aceptar posibles planes de "back-out". Ciertos

entornos de produccin pueden elegir "ignorar" lo problemas que una

nueva versin puede provocar en otras reas y resistirse a volver a la

ltima versin estable.

La implementacin sincronizada de versiones en entornos altamente

distribuidos.

La solucin a estos problemas pasa por:

Un firme compromiso de la organizacin con la Gestin de Versiones y

sus responsables.

Un adecuado plan de comunicacin que informe a todos los

responsables y usuarios de la organizacin TI de las ventajas de una

correcta gestin de todo el proceso de cambio.



Una versin es un grupo de CIs de nueva creacin o modificados que han sido

validados para su instalacin en el entorno de produccin. Las especificaciones

funcionales y tcnicas de una versin estn determinadas en la RFC

correspondiente.

2.3 Clasificacin de las Versiones

Las versiones pueden clasificarse, segn su impacto en la infraestructura TI,

en:

Versiones mayores: que representan importantes despliegues de

software y hardware y que introducen modificaciones importantes en la

funcionalidad, caractersticas tcnicas, etc.

Versiones menores: que suelen implicar la correccin de varios errores

conocidos puntuales y que a menudo son modificaciones que vienen a

implementar de una manera correctamente documentada soluciones de

emergencia.

Versiones de emergencia: modificaciones que reparan de forma rpida

un error conocido.

Como pueden llegar a existir mltiples versiones es conveniente definir una

referencia o cdigo que los identifique unvocamente. El sistema

universalmente aceptado es:

Versiones mayores: 1.0, 2.0, etc.

Versiones menores: 1.1, 1.2, 1.3, etc.

Versiones de emergencia: 1.1.1, 1.1.2, etc.

Aunque en algunos casos esta clasificacin se refina an ms (vea, por

ejemplo, en la ayuda la versin de su navegador).



En su ciclo de vida una versin puede encontrase en diversos estados:

desarrollo, pruebas, produccin y archivado.11

En la Figura 8 nos ilustra grficamente la evolucin temporal de una versin:

Figura 8: Evolucin temporal de una versin

El despliegue de nuevas versiones puede realizarse de diferentes maneras y

es responsabilidad de la Gestin de Cambios el determinar la forma ms

conveniente de hacerlo. Entre las opciones ms habituales cabe contar:

Versin delta: slo se testean e instalan los elementos modificados.

Esta opcin tiene como ventaja su mayor simplicidad pero conlleva el

peligro de que puedan aparecer problemas e incompatibilidades en el

entorno de produccin.

Versin completa: Se distribuyen todos los elementos afectados ya

hayan sido modificados o no. Aunque esta opcin es obviamente ms

trabajosa es ms improbable que se generen incidentes tras la

instalacin si se han realizado las pruebas pertinentes.

11

http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/conceptos_basicos_gestion_de_versiones.php



Paquete de Versiones: La Gestin de Cambios puede optar por

distribuir de forma sincronizada diferentes paquetes de versiones, de

esta forma se ofrece una mayor estabilidad al entorno TI. En algunos

casos esta opcin es obligada por incompatibilidades entre una nueva

versin con software o hardware previamente instalado. Pensemos, por

ejemplo, en la migracin a un nuevo sistema operativo que requiere

hardware ms avanzado y/o nuevos versiones de los programas

ofimticos.

2.4 Visin General

La Gestin de Versiones es la encargada de la implementacin y control de

calidad de todo el software y hardware instalado en el entorno de produccin.

La Gestin de Versiones debe colaborar estrechamente con la Gestin de

Cambios y de Configuraciones para asegurar que toda la informacin relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

sta se halle correctamente actualizada y ofrezca una imagen real de la

configuracin de la infraestructura TI.12

La Gestin de Versiones tambin debe mantener actualizada la Biblioteca de

Software Definitivo (DSL), donde se guardan copias de todo el software en

produccin, y el Depsito de Hardware Definitivo (DHS), donde se almacenan

piezas de repuesto y documentacin para la rpida reparacin de problemas de

hardware en el entorno de produccin.

Las interacciones y funcionalidades de la Gestin de Versiones se resumen

sucintamente en la siguiente Figura 9:

12

http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/conceptos_basicos_gestion_de_versiones.php



Figura 9: Visin General de la Gestin de Versiones

2.5 Planificacin

Es crucial establecer un marco general para el lanzamiento de nuevas

versiones que fije una metodologa de trabajo. Esto es especialmente

importante para los casos de versiones menores y de emergencia pues en el

caso de lanzamientos de gran envergadura se deben desarrollar planes

especficos que tomen en cuenta las peculiaridades de cada caso.

A la hora de planificar correctamente el lanzamiento de una nueva versin se

deben de tomar en cuenta los siguientes factores:

Cmo puede afectar la nueva versin a otras reas del entramado TI.

Qu CIs se vern directa o indirectamente implicados durante y tras el

lanzamiento de la nueva versin.

Cmo ha de construirse el entorno de pruebas para que ste sea fiel

reflejo del entorno de produccin.



Qu planes de back-out son necesarios.

Cmo y cundo se deben implementar los planes de back-out para

minimizar el posible impacto negativo sobre el servicio y la integridad del

sistema TI.

Cules son los recursos humanos y tcnicos necesarios para llevar a

cabo la implementacin de la nueva versin con garantas de xito.

Quines sern los responsables directos en las diferentes etapas del

proceso

Qu planes de comunicacin y/o formacin deben desarrollarse para

que los usuarios estn puntualmente informados y puedan percibir la

nueva versin como una mejora.

Qu tipo de despliegue es el ms adecuado: completo, delta,

sincronizado en todas los emplazamientos, gradual, ...

Cul es la vida media til esperada de la nueva versin.

Qu impacto puede tener el proceso de lanzamiento de la nueva versin

en la calidad del servicio.

Si es posible establecer mtricas precisas que determinen el grado de

xito del lanzamiento de la nueva versin.

2.6 Desarrollo

La Gestin de Versiones es la encargada del diseo y construccin de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes.

A veces el desarrollo se realizara "en la casa" y muchas otras requerir la

participacin de proveedores externos. En este segundo caso, la tarea de la

Gestin de Versiones ser la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC. Asimismo, la Gestin de Versiones ser la responsable de todo el

proceso de configuracin necesario.



El desarrollo debe incluir, si esto fuera necesario o simplemente recomendable,

todos los scripts de instalacin necesarios para el despliegue de la versin.

Estos scripts debern tener en cuenta aspectos tales como:

Back-up automtico de datos.

Actualizaciones necesarias de las Bases de Datos asociadas.

Instalacin de las nuevas versiones en diferentes sistemas o

emplazamientos geogrficos.

Creacin de logs asociados al proceso de instalacin.

Parte integrante del desarrollo lo componen los planes de back-out asociados.

Estos tendrn que tomar en cuenta la disponibilidad acordada con los clientes

en los SLAs correspondientes.

2.7 Validacin

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccin una nueva versin con razonables garantas de

xito.

Las pruebas no deben limitarse a una validacin de carcter tcnico (ausencia

de errores) sino que tambin deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versin cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracin).

Es importante que las pruebas incluyan los planes de back-out para

asegurarnos que se podr volver a la ltima versin estable de una forma

rpida, ordenada y sin perdidas de valiosa informacin.

Las principales actividades realizadas en el proceso de prueba deben incluir:

Pruebas del correcto funcionamiento de la versin en un entorno

realista.



Pruebas de los procedimientos automticos o manuales de instalacin.

Listas de "bugs" o errores detectados, si se diera el caso.

Pruebas de los planes de back-out.

Documentacin para usuarios y personal de servicio.

La Gestin de Cambios ser la encargada de dar la validacin final a la versin

para que se proceda a su instalacin. Si la versin no fuera aceptada se

devolver a la Gestin de Cambios para su reevaluacin.

2.8 Implementacin

Llego el momento de la verdad: la distribucin de la nueva versin, tambin

conocida como rollout.

El rollout puede ser de varios tipos:

Completo y sincronizado: se realiza de manera integral y simultnea

en todos los emplazamientos.

Fragmentado: ya sea bien espacial o temporalmente. Por ejemplo,

introduciendo la nueva versin por grupos de trabajo o incrementando

progresivamente la funcionalidad ofrecida.

El procedimiento de rollout debe ser cuidadosamente documentado para que

todas las partes conozcan sus tareas y responsabilidades especficas. En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de cmo este puede afectar a sus actividades

diarias.

Es imprescindible determinar claramente:

Los CIs que deben borrarse e instalarse y en que orden debe realizarse

este proceso.

Cundo debe realizarse este proceso para diferentes grupos de trabajo

y/o localizaciones geogrficas.



Que mtricas determinan la puesta en marcha de los planes de back-out

y si estos deben ser completos o parciales.

Tras la distribucin la Gestin de Versiones debe asegurarse de que:

Se incluya una copia de la versin en la DSL.

El DHS incorpore repuestos funcionales de los nuevos CIs.

La CMDB est correctamente actualizada.

Los usuarios estn debidamente informados de las nuevas

funcionalidades y han recibido la formacin necesaria para poder sacar

el adecuado provecho de las mismas.

Tras la implementacin, la Gestin de Versiones debe ser puntualmente

informada por el Service Desk de los comentarios, quejas, incidentes, etc. que

la nueva versin haya podido suscitar. Toda esta informacin deber ser

analizada para asegurar que las prximas versiones incorporen las sugerencias

recibidas y que se tomen las medidas correctivas necesarias para minimizar el

impacto negativo que puedan tener futuros cambios.

2.9 Comunicacin y Formacin

Es frecuente, y a su vez un grave error, que cuando se aborden cuestiones de

carcter tcnico se obvie el factor humano.

Salvo contadas excepciones, es necesaria la interaccin usuario-aplicacin y

sta suele representar el eslabn ms dbil de la cadena.

Es intil disponer de un sofisticado servicio TI si los usuarios , debido a una

incompleta (in)formacin, no se encuentran en disposicin de aprovechar sus

ventajas.



La (in)formacin debe estructurarse en distintos niveles:

Los usuarios deben conocer el prximo lanzamiento de una nueva

versin y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar, a su discrecin, en

el proceso.

Siempre que sea posible las pruebas de carcter funcional deben ser

realizadas por un selecto grupo de usuarios finales. Durante este

proceso de prueba se documentarn y analizarn:

o La experiencia subjetiva de usuario.

o Los comentarios y sugerencias sobre usabilidad y funcionalidad. o

Las dudas que hayan surgido durante el uso de la nueva versin.

o La claridad de la documentacin que se pondr a disposicin del

usuario final.

Cuando se considere oportuno se impartirn cursos presenciales o

remotos mediante mdulos de e-learning sobre el funcionamiento de la

nueva versin.

Se desarrollar una pgina de FAQs donde los usuarios puedan aclarar

las dudas ms habituales y puedan solicitar ayuda o soporte tcnico en

el uso de la nueva versin.

2.10 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestin de Versiones.

Para que estos informes ofrezcan una informacin precisa y de sencilla

evaluacin es necesario elaborar mtricas de referencia que cubran aspectos

tales como:

Nmero de lanzamientos de nuevas versiones.

Nmero de back-outs y razones de los mismos.

Incidencias asociadas a nuevas versiones.



Cumplimientos de los plazos previstos para cada despliegue.

Asignacin de recursos en cada caso.

Correccin y alcance de la CMDB y la DHS.

Existencia de versiones ilegales de software.

Adecuado registro de las nuevas versiones en la CMDB.

Incidencias provocadas por uso incorrecto (formacin inadecuada) de la

nueva versin por parte de los usuarios.

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versin.



CAPITULO 3

CONTROL DE VERSIONES

3.1 Que es un Control de Versiones

Una versin, revisin o edicin de un producto, es el estado en l se encuentra

en un momento dado en su desarrollo o modificacin. Se llama control de

versiones a la gestin de los diversos cambios que se realizan sobre los

elementos de algn producto o una configuracin del mismo. Los sistemas de

control de versiones facilitan la administracin de las distintas versiones de

cada producto desarrollado, as como las posibles especializaciones realizadas

(por ejemplo, para algn cliente especfico).

El control de versiones se realiza principalmente en la industria informtica para

controlar las distintas versiones del cdigo fuente. Sin embargo, los mismos

conceptos son aplicables a otros mbitos como documentos, imgenes, sitios

web, etctera.13

Aunque un sistema de control de versiones puede realizarse de forma manual,

es muy aconsejable disponer de herramientas que faciliten esta gestin (CVS,

Subversion, SourceSafe, ClearCase, Darcs, Plastic SCM, Git, Mercurial, etc.).

3.1.1 Caractersticas

Un sistema de control de versiones debe proporcionar:

Mecanismo de almacenaje de los elementos que deba gestionar (ej.

archivos de texto, imgenes, documentacin...)

Posibilidad de realizar cambios sobre los elementos almacenados (ej.

modificaciones parciales, aadir, borrar, renombrar o mover elementos)

13

http://macprogramadores.org/tutoriales/tutoriales/cvssvn.pdf



Registro histrico de las acciones realizadas con cada elemento o

conjunto de elementos (normalmente pudiendo volver o extraer un

estado anterior del producto)

Aunque no es estrictamente necesario, suele ser muy til la generacin de

informes con los cambios introducidos entre dos versiones, informes de estado,

marcado con nombre identificativo de la versin de un conjunto de ficheros,

etctera.

3.1.2 Clasificacin

La principal clasificacin que se puede establecer est basada en el

almacenamiento del cdigo:

Centralizados: existe un repositorio centralizado de todo el cdigo, del

cual es responsable un nico usuario (o conjunto de ellos). Se facilitan

las tareas administrativas a cambio de reducir la potencia y flexibilidad,

pues todas las decisiones fuertes (como crear una nueva rama)

necesitan la aprobacin del responsable. Algunos ejemplos son CVS y

Subversion

Distribuidos: se aumenta la capacidad de decisin distribuida. Esto da

ms flexibilidad pero puede dificultar bastante la sincronizacin.

Ejemplos: GIT y GNU Arch

3.1.3 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio, que es el conjunto de informacin gestionada por el sistema. Este

repositorio contiene el historial de versiones de todos los elementos

gestionados.

Cada uno de los usuarios puede crearse una copia local duplicando el

contenido del repositorio para permitir su uso. Es posible duplicar la ltima

versin o cualquier versin almacenada en el historial. Este proceso se suele



conocer como check out o desproteger. Para modificar la copia local existen

dos semnticas bsicas:

Exclusivos: para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargar

de impedir que otro usuario pueda modificar dicho elemento.

Colaborativos: en el que cada usuario se descarga la copia la modifica

y el sistema automticamente mezcla las diversas modificaciones. El

principal problema es la posible aparicin de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas. Adems,

esta semntica no es apropiada para ficheros binarios.

Tras realizar la modificacin es necesario actualizar el repositorio con los

cambios realizados. Habitualmente este proceso se denomina commit, check in

o proteger.

3.2 DSL (Definitive Software Library)

La Biblioteca de Software Definitivo (DSL) debe contener copia de todo el

software instalado en el entorno TI. Esto incluye no solo sistemas operativos y

aplicaciones sino tambin controladores de dispositivos y documentacin

asociada.

La DSL debe contener el histrico completo de versiones de un mismo software

para proporcionar la versin necesaria en caso de que se deban implementar

los planes de back-out.14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up peridicos.

14




3.3 DHS (Depsito de Hardware Definitivo)

El Depsito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccin.

Los activos almacenados deben incorporarse a la CMDB (Database Change &

Configuration Management) en el caso de que los CIs correspondientes se

hallen registrados en la misma (esto puede depender del alcance y nivel de

detalle de la CMDB).

Las principales actividades de la Gestin de Versiones se resumen en:

Establecer una poltica de planificacin para la implementacin de

nuevas versiones.

Desarrollar o adquirir de terceros las nuevas versiones.

Poner a prueba las nuevas versiones en un entorno que simule lo mejor

posible el entorno de produccin.

Validar las nuevas versiones.

Implementar las nuevas versiones en el entorno de produccin.

Llevar a cabo los planes de back-out o retirada de la nueva versin si

esto fuera necesario.

Actualizar la DSL, el DHS y la CMDB.

Comunicar y formar a los clientes y usuarios sobre las funcionalidades

de la nueva versin.



CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

4.1 Introduccin

Los gestores de versiones (version control system), tambin llamados

herramientas de gestin de configuraciones software o repositorios, son

herramientas que permiten a los programadores de un proyecto centralizar y

coordinar sus trabajos. Los gestores de versiones son especialmente tiles

para todo tipo de documentos que sean revisados frecuentemente, como

pueda ser el cdigo fuente de un programa, su documentacin, cartas, etc...

Normalmente uno de los programadores va a ser el administrador del gestor de

versiones, que es el que se encargara de administrar y dar permisos en el

gestor de versiones, aunque esta tarea se puede tambin delegar en una

persona especializada en la administracin de sistemas informticos.

Aunque los gestores de versiones estn pensados para grupos de trabajo,

tambin son muy tiles para un programador individual, ya que le ayuda a

llevar una cuenta histrica de las diferentes versiones de sus ficheros.

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestin de versiones:

RCS (Revision Control System). El ms antiguo de todos, y que adems

tiene su cdigo fuente publicado de forma gratuita por la Free Software

Foundation. Prcticamente todos los sistemas UNIX lo tienen, y Mac OS X

tambin lo trae preinstalado.

SCCS (Source Code Control System). Fue introducido por AT&T en el

Sistema V de UNIX, y actualmente forma parte del estndar X/Open. Sin

embargo Mac OS X no lo trae preinstalado, y nosotros no lo

estudiaremos.



CVS (Concurrent Version System). Est basado en ReS, y actualmente

es el gestor de versiones ms utilizado por los desarrolladores de software

libre en Internet.

Subversin. Es el resultado de un reingeniera sobre los conceptos de evs

para buscar una solucin alternativa a los problemas ms comunes con lo

que se encuentran los usuarios de evs. Actualmente, su volumen de

usuarios est creciendo rpidamente.

En este documento estudiaremos evs y Subversin. Aunque usaremos Mac OS

X para todos los ejemplos, su interoperatividad hace que las explicaciones

puedan ser aplicadas sin problemas en otros entornos UNIX o Windows.

4.2 Porqu usar un repositorio

Los proyectos de desarrollo de software implican tener a varios desarrolladores

trabajando de forma concurrente sobre varios conjuntos de ficheros que con

frecuencia se solapan. En consecuencia resulta fundamental poder trazar los

cambios hechos por los programadores, de forma que siempre sepamos quin

es el responsable de cada cambio. Para ello los gestores de versiones

mantienen un sistema de logs. Adems los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior. Tambin es

importante que el gestor de versiones permita mezclar 105 cambios realizados

por 105 distintos programadores. Los principales argumentos a favor de usar

un gestor de versiones son:

Persistencia. Manteniendo un histrico de revisiones desaparece el

problema de perder un cdigo cuando se modifica. Adems mantener el

cdigo del proyecto centralizado ayuda a realizar copias de seguridad.

Integracin. La integracin se realiza implcitamente segn los

programadores guardan sus contribuciones en el repositorio.

Contabilidad. Es importante saber quin y cundo se ha realizado cada



cambio en el proyecto. El gestor de versiones permite guardar un histrico

de quin ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio.

Branching. Un mismo cdigo se puede utilizar en varios proyectos con slo

hacer pequeas modificaciones. Los gestores de versiones permiten crear una

lnea base llamada tronco (trunk) y varias ramas (branches) de un cdigo

fuente. Adems, el gestor de versiones ayuda a combinar el contenido de las

ramas con el tronco. Por ejemplo, un proyecto puede tener un tronco de

desarrollo, y una o ms ramas para mantenimiento de errores en versiones

release antiguas. Esto evita el quebradero de cabeza de tener que mantener

sincronizadas varias versiones similares de un cdigo fuente.

Trabajo distribuido. Los gestores de versiones modernos permiten

almacenar el cdigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a travs de Internet.

4.3 Revisiones, versiones release y variantes

Los gestores de versiones mantienen una copia de todos los ficheros que

guardamos en el repositorio a lo largo del ciclo de vida del proyecto, de forma

que en cualquier momento podemos "dar marcha atrs" y recuperar una

versin que tenamos guardada. 15

Para ello a las diferentes versiones se las da un nmero de versin, al que

llamaremos revisin, que nos sirve para identificar luego cada versin que

hayamos guardado. Aunque muchas veces en la literatura a las revisiones

tambin se las llama versiones, nosotros usaremos el trmino revisiones para

evitar confusiones innecesarias.

Conviene diferenciar entre versiones release de un programa y revisiones. Las

15




versiones release son versiones que se sacan al pblico cuando conseguimos

tener el programa en un estado estable, mientras que las revisiones son las

que crea el programador cuando al final del da decide guardar su trabajo en el

repositorio. Es decir, no tenga miedo de guardar tantas revisiones como quiera.

Por ltimo conviene comentar que el trmino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (p.e. para

distintos sistemas operativos).

4.4 Modelos de configuracin

Se llama modelo de configuracin a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre. El modelo de

configuracin es el producto cartesiano de dos espacios, el espacio de

producto y el espacio de reversiones:

El espacio de producto son los ficheros que componen el proyecto y las

relaciones entre ellos, las cuales pueden ser de dos tipos: Composicin, donde

un fichero est formado por otros (p.e. las relaciones include), y dependencia

donde el contenido de un fichero depende de otro fichero.

El espacio de reversiones muestra la evolucin de un fichero a lo largo del

tiempo.

Los gestores de versiones estn pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente, es decir, slo almacenan los

cambios realizados a cada fichero, no todo el fichero. Se llama delta a la

diferencia entre dos revisiones, y los deltas se pueden representar de dos

formas 16

16




1. Representacin simtrica donde dadas dos revisiones de un fichero T1

y T2, se almacenan las lneas de texto que estn en T1 y no estn en T2, y

las que estn en T2 y no estn en T1 (vase Figura 1.1), es decir, se

almacena que lneas de texto estn en cada versin y no en la otra.

2. Representacin por cambios. Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2.

4.5 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

tcnicas de versionado:

El ms conocido y normal es el versionado extensional (por aadidos), donde

se va numerando el contenido de cada fichero segn evoluciona, es decir, los

cambios que vamos haciendo al fichero en las distintas revisiones.

El otro tipo de versionado es el versionado intensional (que significa dividir en

partes), el cual nos permite que de una configuracin del software haya varias

variantes, y al acceder a la herramienta de gestin de versiones indicamos qu

versin es la que queremos coger (p.e. Xll para Linux, Cocoa para Mac OS X, o

Win32 para Windows). Este versionado es muy tpico gestionarlo con directivas

del propio lenguaje como por ejemplo de C.

4.6 Gestores de versiones orientados a ficheros y a proyectos.

En funcin de la forma en que se asignan revisiones, existen dos tipos de

gestores de versiones. Los gestores de versiones orientados a ficheros (p.e.

CVS), donde los nmeros de revisin se asignan para cada fichero de forma

individual, y los gestores de versiones orientados a proyectos (p.e.

Subversin), donde el nmero de revisin se asigna a todos los ficheros que

componen el proyecto en un momento dado.



La Figura 1.2 muestra un ejemplo de nmeros de revisin asignados a los

ficheros de un proyecto en un momento dado, en el caso de CVS. Como

vemos, cada fichero tiene un nmero de revisin distinto, que corresponde con

el nmero de veces que se ha modificado y guardado el fichero en el

repositorio. 17

Las revisiones de nmero ms alto de cada fichero corresponden al estado

actual del proyecto. En los repositorios orientados a ficheros, como cada

fichero crece de forma independiente, es comn realizar el tagging, que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado, con el fin de poder recuperar ms tarde ese estado. En CVS se puede

usar la etiqueta especial HEAD para referirse las ltimas revisiones de todos

los ficheros del proyecto.

Figura 10. Ejemplo de repositorio orientado a ficheros

17




CAPITULO V

ELEMENTOS DEL REPOSITORIO

5.1 Interaccin con el repositorio

Normalmente se llama repositorio a un directorio situado en una mquina (que

acta como servidor) donde se almacenan uno o ms proyectos. Por cada

proyecto se suele crear un subdirectorio dentro del directorio de repositorio que

contiene los ficheros del proyecto. A este directorio se le llama directorio de

proyecto. El repositorio puede estar situado en la misma mquina que el

programador, pero es ms comn colocar en repositorio en una mquina

distinta y conectarse al repositorio a travs de Internet siguiendo el modelo

cliente servidor.

Los desarrolladores actan como clientes, y suelen bajarse una copia de uno o

ms proyectos a directorios de su mquina de trabajo. A la copia de un

proyecto se la llama sandbox (nomenclatura CVS), o working copy

(nomenclatura Subversion). Tanto en CVS como en Subversion existe una

nomenclatura homognea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto, que son las siguientes:

1. Import. Es la operacin de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la mquina local. Esta operacin

suele realizarse slo una vez al principio de un proyecto.

2. Checkout. Es la operacin de bajarse un proyecto desde el repositorio a un

directorio de la mquina local. Este directorio es el sandbox, y adems de

los ficheros del proyecto, contiene algunos ficheros con metadatos que

sirven al gestor de versiones para conocer informaciones como los logs o

las revisiones de un fichero. Esta operacin la realiza normalmente slo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio.

3. Export. Es una operacin parecida a checkout, pero en vez de estar



destinada a programadores que desean crearse una sandbox, est

destinada a usuarios que quieren bajarse el cdigo fuente sin ficheros

adicionales de metadatos. Es decir, con la operacin export, el usuario no

obtiene un sandbox, sino slo un directorio con los ficheros del proyecto

listos para ser compilados.

4. Commit. Una vez que el desarrollador modifica uno o ms ficheros del

proyecto, ste debe subir los cambios al proyecto del repositorio usando la

operacin de commit. Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcin de los cambios

realizados.

S. Update. Cuando un programador actualiza el proyecto, los dems

desarrolladores pueden bajarse estos cambios utilizando la operacin de

update.

Los gestores de versiones permiten que un programador modifique su sandbox

y, sin necesidad de hacer un commit de los cambios, ejecute la operacin de

update. En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox slo las lneas de cdigo cambiadas en el

proyecto del repositorio.

Cuando un programador empieza a trabajar con un gestor de versiones suele

empezar teniendo bastante miedo a que un update le estropee su cdigo: No

tenga ningn miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto ms frecuentemente lo haga

mejor) y no se preocupe si otros programadores estn tambin modificando el

proyecto del repositorio. Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su cdigo. En la seccin 2 veremos que a

veces se pueden producir conflictos, pero que su resolucin es ms sencilla de

lo que pueda parecer.

En cualquier caso, y como regla general, se recomienda seguir el siguiente

paradigma de interaccin con el proyecto del repositorio:



La operacin de update la puede realizar tantas veces como quiera. Por

ejemplo la puede realizar todos los das por la maana antes de ponerse a

trabajar en su proyecto, o despus de venir de comer. Si su cdigo

compilaba antes del update, deber seguir compilando despus del update.

Si no es as puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quin ha subido el cambio, y vaya a hablar con

l inmediatamente. Si en su grupo de trabajo es frecuente que el cdigo

deje de compilar correctamente despus de hacer un update, es un sntoma

de que una o ms personas en su grupo de trabajo no son muy

competentes.

La operacin de commit se debe realizar slo inmediatamente despus de

hacer un update, y slo cuando se dispone de un cdigo que compila y ejecuta

correctamente. La primera condicin garantiza que si otro programador ha

actualizado el proyecto del repositorio los cambios del otro programador sean

consistentes con los que usted ha realizado. De hecho, los gestores de

versiones impiden realizar un commit cuando hay cambios en el proyecto del

repositorio que no se han bajado al sandbox con update. La segunda condicin

garantiza que los dems programadores no se encuentren con un proyecto con

cdigo que ni siquiera compila: Un sntoma claro de que el gestor de versiones

no se est usando correctamente. Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados: Cuando ms

se alarguen los periodos de commit, ms trabajo se perder si su mquina falla.

Cuando se hace commit, el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado. Es muy comn que el programador

utilice mensajes poco significativos en estos comentarios, los cuales recuden

considerablemente su utilidad. Es muy importante que utilice mensajes

informativos que puedan ser luego interpretados por otros programadores.

Entre los aspectos que debera incluir este mensaje estn: Por qu se ha

hecho el cambio, qu funcionalidad se ha aadido, cambiado, y eliminado. Por

ltimo conviene comentar que un error comn por parte de los recin llegados



a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto. En general, en un repositorio slo deben de

almacenarse los ficheros de cdigo fuente (p.e .. e, .h, Makefile) que sirven

para generar el programa, as como los ficheros de documentacin (p.e. . doe, .

ppt), pero no deberamos de almacenar los ficheros que se producen durante la

generacin del programa, como los. 0, los .lib, los. dll o los. exe. Estos ficheros

hacen crecer mucho el tamao del repositorio, y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de cdigo fuente. En

general, los ficheros de proyecto que crean muchas herramientas de desarrollo

tampoco se deben de guardar en el repositorio ya que estos ficheros contienen

paths que dependen de la mquina donde se site el sandbox. Los ficheros

Makefile o Ant son una excepcin a esta regla siempre que se diseen de

forma que no dependan de rutas absolutas. En el caso de que nuestro proyecto

utilice ficheros de ejemplo, como imgenes. jpg, o vdeos . mpg, estos tambin

se pueden almacenar en un directorio destinada a iconos o casos de prueba.

5.2 Resolucin de conflictos

Tanto CVS como Subversin siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despus el gestor de versiones se encarga de realizar la mezcla de ficheros.

Otros gestores de versiones como Microsoft Visual SourceSafe siguen un

paradigma de bloqueos, donde un programador cuando va a codificar un

fichero, primero lo bloquea, luego lo modifica, y luego libera el bloqueo.

Los gestores de versiones realizan la mezcla de ficheros de texto lnea a lnea.

Si 105 cambios estn en diferentes lneas, el sistema aade, reemplaza o

elimina lneas segn proceda. La operacin de mezcla ser satisfactoria

siempre que dos programadores no hayan modificado la misma lnea. En caso

de que ambos hayan modificado la misma lnea se producir un conflicto (a no

ser que hayan modificado exactamente las mismas lneas con el mismo

contenido).



En teora la operacin de mezcla podra realizarse tanto en la operacin de

commit como en la operacin de update, pero debido a que los gestores de

versiones impiden realizar un commit cuando hay cambios en el proyecto del

repositorio (es decir, cuando nuestra revisin del sandbox es ms antigua que

la del proyecto del repositorio), la operacin de mezcla siempre se realiza

durante el update. Tngase en cuenta que la operacin de mezcla siempre se

realiza entre un fichero en el proyecto del repositorio y otro en el sandbox, y el

resultado de la mezcla siempre acaba depositndose en el sandbox.

Cuando nos encontramos un conflicto, para resolver el conflicto el gestor de

versiones nos muestra dos ficheros: el fichero con los cambios que hemos

hecho en el sandbox, y el fichero con los cambios que otro programador hizo

en el proyecto del repositorio, y se nos seala la o las lneas conflictivas. En

este momento debemos indicar cul de las dos lneas es la correcta (para lo

cual, si tenemos dudas, podemos consultar al otro programador). Una vez

indicado cul es la lnea o lneas correctas, obtendremos en el sandbox el

fichero actualizado y con los cambios aplicados. En este momento podremos

evaluar si todo compila y ejecuta correctamente, y subir 105 cambios al

proyecto del repositorio con la operacin de commit.

5.3 Tagging

Aunque poder obtener la ltima revisin de 105 ficheros de un proyecto en el

repositorio es til, tambin es muy til poder obtener los ficheros del proyecto

en la revisin en la que se encontraban en algn hito pasado (p.e. en la versin

1.0 del proyecto). El tagging permite poner una etiqueta a los ficheros del

proyecto tal como se encuentran en un momento dado por si en el futuro

quisiramos obtener est configuracin.

En el caso de CVS, como muestra la Figura 1.2, a los ficheros se les asigna

nmeros de revisin de forma individual, con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nmero de revisin actual. Por

su parte, Subversin implementa el tagging mediante copias ligeras (cheap



copies), que consiste en hacer una copia del proyecto (que normalmente est

en un directorio llamado trunk) en otro directorio (que normalmente estar

metido dentro del directorio tags).

Subversion no asigna nmeros de revisin de forma individual a cada fichero,

sino que por cada revisin que guardamos en el proyecto del repositorio asigna

un nmero de revisin para todos los ficheros del proyecto. Cuando en

Subversion hacemos una copia ligera, no estamos copiando el contenido del

fichero (en la revisin actual y en todas las anteriores) sino que slo estamos

apuntando al contenido de la revisin actual en otra ruta. Esto permite que el

tagging no consuma muchos recursos. Debido a que las copias ligeras son un

puntero a una revisin, slo pueden hacerse copias ligeras de todos los

ficheros del proyecto.

Las estrategias de tagging son muy diversas, pero momentos tpicos en los que

se hace tagging del proyecto son: Cuando se cumple un hito, cuando se

termina una versin release del proyecto, antes de empezar a eliminar una

funcionalidad, o antes de empezar a modificar la forma en que est

implementada una parte del proyecto.

5.4 Branching

A la lnea principal de desarrollo normalmente se la llama tronco (trunk). El

branching consiste en crear una o ms lneas de desarrollo distintas a las que

se llama ramas (branches).

Existen varias razones para crear una rama: Una razn muy usada es para

mantenimiento y correccin de errores de una versin release del producto

mientras que el tronco se utiliza para aadir nueva funcionalidad. Otra razn es

crear una rama para hacer cambios experimentales o reingeniera de cdigo

que en el futuro se podrn aadir o no al tronco de la aplicacin.



El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Cdigo, hasta que llegado un cierto punto, llamado base de la

rama, el gestor de versiones almacena los cambios en el tronco y en la rama

de forma separada.

En general, deberamos saber que conviene crear una rama antes de empezar

a modificar el cdigo, pero en ocasiones no se decide que conviene crear una

rama hasta que el cdigo ha empezado a ser modificado, en este caso

podemos hacer un branching retroactivo, pero hacer un branching retroactivo

siempre es ms complicado que si desde el principio se decide empezar a

trabajar en otra rama.

En Subversin la rama debe de incluir todos los ficheros del proyecto. Por

contra CVS permite que la rama slo incluya uno o ms ficheros, pero

experimentalmente se sabe que siempre que se va a crear una rama, es mejor

incluir todos los ficheros del proyecto. En caso contrario es muy comn que

acabe necesitndose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento. 18

5.4.1 Nmeros de revisin

Tanto CVS como Subversin asignan un nmero diferente a cada revisin que

almacenamos en el proyecto del repositorio, pero la forma de numerar las

revisiones difiere en dos aspectos:

El primer aspecto es que, como adelantamos en el apartado 6 del Tema 1,

Subversin es orientado a proyecto, es decir, asigna un mismo nmero de

revisin a todos los ficheros que componen el proyecto en un momento dado,

mientras que CVS es orientado a fichero, es decir, tal como muestra la Figura

1.2, a cada fichero se le va asignando nmeros de revisin distintos.

18




El segundo aspecto a destacar es que Subversin utiliza nmeros consecutivos

para cada revisin que se guarda en el proyecto del repositorio,

independientemente de si la revisin corresponde al tronco o a una rama. En la

Figura 11(a) vemos que los nmeros de revisin en el tronco y en la rama no

tienen porque ser consecutivos.

Sin embargo, como muestra la Figura 11 (b), CVS asigna nmeros de revisin

compuestos por varios nmeros separados por punto. En el caso del tronco el

nmero de revisin suele1 empezar por 1, y despus le sigue el nmero de

revisin del tronco. En el caso de las ramas, las ramas estn formadas por tres

dgitos. Los dos primeros dgitos indican la base de la rama, y el tercero es un

nmero par que indica el nmero de rama para esa revisin. Por ltimo el

cuarto dgito se destina a indicar el nmero de revisin para una rama.

En cualquier caso la forma en que un gestor de versiones asigna nmeros a las

revisiones debe ser vista de forma transparente por parte del usuario, es decir,

no se preocupe por qu nmero de revisin le corresponde a cada revisin que

guarde. Si le interesa recordar una revisin por algn motivo, utilice tagging. 19

Figura 11.(a)Branching

Figura 11.(b) Branching en supervisin

19




5.4.2 Mezclar ramas

Podemos hacer una operacin de mezcla consistente en aplicar una rama al

tronco, en cuyo caso aplicamos los cambios que h3ya sufrido la rama, durante

las revisiones de sta, a la revisin ms reciente del tronco. Cundo esta

mezcla es deseable, depende de la finalidad para la que se cre la rama: Si es

una rama de mantenimiento y correccin de errores, seguramente sea

deseable hacer esta mezcla. Tambin podra ser interesante aplicar esta

mezcla si la rama se cre para desarrollar un cdigo experimental o para hacer

reingeniera de cdigo, y el trabajo realizado en la rama fue satisfactorio.

1 Es posible crear varios troncos para un mismo fichero, en cuyo caso el

nmero empezara por 2, 3, etc, pero es algo que no se recomienda y no

vamos a estudiar aqu. Es decir, el primer dgito indica el nmero de tronco.

2 Puede crearse una rama de una rama, pero crear ramas anidadas es algo

que tampoco se recomienda por la complejidad que introduce.

Tambin es posible aplicar un tronco a una rama, en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisin ms reciente de la rama.

5.4.3 Estrategias de branching

En general el tronco representa la principal lnea de desarrollo del proyecto,

todas las variantes deberan almacenarse en ramas. El principal problema

surge a la hora de decidir si el tronco debera mantener cdigo estable o si el

mantenimiento y reparacin de errores debera realizarse en las ramas. Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacin: Troncos estables y troncos inestables.

5.4.4 Troncos estables

La estrategia de troncos estables dice que el tronco debera mantener cdigo

que est siempre listo para release. Las ramas se usan para desarrollo,

introducir nueva funcionalidad experimental, para refactorizacin de cdigo, etc.



La variante ms estricta de esta estrategia dice que nada debe de mezclarse

en el tronco hasta que no haya pasado por un proceso de aseguramiento de

calidad.

En el caso del cdigo fuente abierto, la estrategia de troncos estables es la ms

popular, ya que cualquier usuario puede bajarse en cualquier momento el

cdigo de nuestro proyecto del repositorio, compilarlo, y todo le debera de

funcionar.

Otra variante menos estricta dice que el cdigo se enva al tronco una vez

acabado (lo que se suele llamar versin beta o release candidate), y en este

momento se crea una rama de aseguramiento de calidad, que es la rama de la

que saldr la versin release del producto. A partir del momento en que

saquemos la versin release del producto, se crea una rama de mantenimiento,

en la que se corrigen posibles errores que surjan ms adelante en la versin

publicada.

Las ventajas de esta estrategia son que siempre tenemos cdigo estable en el

tronco, y que si los desarrollos que hacemos en una rama acaban retrasndose

indefinidamente o no terminan de funcionar, no tenemos que deshacer los

cambios que haya sufrido el tronco.

La principal desventaja de la estrategia de troncos estables es que el cdigo de

la rama puede diferir bastante del cdigo del tronco, con lo que la mezcla con el

tronco la debe de realizar una persona que conozca bien los cambios que se

han desarrollado en la rama.

5.4.5 Troncos inestables

En esta estrategia, el tronco se utiliza para ir guardando las ltimas version

Documents

Bilioteca de infraestructura de tecnología de información (ITIL) Gestión de versiones VERSIONES.pdf