INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca...

68
ITIL: GESTION DE VERSIONES Investigador: María Eugenia Bravo Campoverde Pagina 1 CAPITULO I INTRODUCCIÓN A ITIL 1.1 Definición de ITIL ITIL son las siglas de una metodología desarrollada a finales de los años 80’s por iniciativa del gobierno del Reino Unido, específicamente por la OGC u Oficina Gubernativa de Comercio Británica (Office of Goverment Comerce). Las siglas de ITIL significan (Information Technology Infrastructure Library) o Librería de Infraestructura de Tecnologías de Información. Esta metodología es la aproximación más globalmente aceptada para la gestión de servicios de Tecnologías de Información en todo el mundo, ya que es una recopilación de las mejores prácticas tanto del sector público como del sector privado. Estas mejores prácticas 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 evaluación e implementación. ITIL brinda una descripción detallada de un número de prácticas importantes en IT, a través de una amplia lista de verificación, tareas, procedimientos y responsabilidades que pueden adaptarse a cualquier organización IT. En algunos casos hasta se han definido las prácticas como procesos que cubren las actividades más 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 organización IT. La organización puede crecer y madurar con ellos. En base a ITIL se han desarrollado varios sistemas para la Administración 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 estándar de facto para describir varios procesos

Transcript of INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca...

Page 1: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 1

CAPITULO I

INTRODUCCIOacuteN A ITIL

11 Definicioacuten de ITIL

ITIL son las siglas de una metodologiacutea desarrollada a finales de los antildeos 80rsquos

por iniciativa del gobierno del Reino Unido especiacuteficamente por la OGC u

Oficina Gubernativa de Comercio Britaacutenica (Office of Goverment Comerce) Las

siglas de ITIL significan (Information Technology Infrastructure Library) o

Libreriacutea de Infraestructura de Tecnologiacuteas de Informacioacuten

Esta metodologiacutea es la aproximacioacuten maacutes globalmente aceptada para la

gestioacuten de servicios de Tecnologiacuteas de Informacioacuten en todo el mundo ya que

es una recopilacioacuten de las mejores praacutecticas tanto del sector puacuteblico como del

sector privado Estas mejores praacutecticas 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 evaluacioacuten e implementacioacuten

ITIL brinda una descripcioacuten detallada de un nuacutemero de praacutecticas importantes en

IT a traveacutes de una amplia lista de verificacioacuten tareas procedimientos y

responsabilidades que pueden adaptarse a cualquier organizacioacuten IT En

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

las actividades maacutes 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 uacutetil para fijar nuevos objetivos de mejora para la

organizacioacuten IT La organizacioacuten puede crecer y madurar con ellos

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

Servicio IT generalmente organizaciones del negocio Los ejemplos incluyen

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

Proceso) Microsoft (MOF) y muchos otros Eacutesta es una de las razones por las

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

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 2

fundamentales de la Administracioacuten de Servicio IT Esta adopcioacuten y adaptacioacuten

de ITIL refleja la filosofiacutea de ITIL y es un desarrollo bienvenido ya que la ITIL

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

medio heterogeacuteneo y dividido de IT

ITIL fue desarrollada al reconocer que las organizaciones dependen cada vez

maacutes 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 comuacuten para todas las actividades del departamento IT

como parte de la provisioacuten de servicios basado en la infraestructura IT Estas

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

Administracioacuten de Servicio IT maacutes madura Cada uno de estos procesos cubre

una o maacutes tareas del departamento IT tal como desarrollo de servicio

administracioacuten de infraestructura y provisioacuten y soporte de los servicios Este

planteo del proceso permite describir las mejores praacutecticas de la Administracioacuten

de Servicio IT independientemente de la estructura de organizacioacuten real de la

entidad

12 El objetivo de usar ITIL en Managed Services

ITIL como metodologiacutea propone el establecimiento de estaacutendares que nos

ayuden en el control operacioacuten y administracioacuten de los recursos (ya sean

propios o de los clientes) Plantea hacer una revisioacuten y reestructuracioacuten de los

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

es bajo o que haya una forma maacutes 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 documentacioacuten pertinente ya que esta puede ser de gran

utilidad para otros miembros del aacuterea ademaacutes de que quedan asentados todos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 3

los movimientos realizados permitiendo que toda la gente esteacute al tanto de los

cambios y no se tome a nadie por sorpresa

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

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

cambio asiacute como quien es el que autorizo el cambio para que asiacute se lleve todo

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

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

y asiacute 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

bull Mejora la comunicacioacuten con los clientes y usuarios finales a traveacutes de los

diversos puntos de contacto acordados

bull Los servicios se detallan en lenguaje del cliente y con maacutes detalles

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

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

calidad de los mismos y relacioacuten entre el cliente y el departamento de IT

bull Una mayor flexibilidad y adaptabilidad de los servicios

Ventajas de ITIL para TI

bull La organizacioacuten TI desarrolla una estructura maacutes clara se vuelve maacutes eficaz

y se centra maacutes en los objetivos de la organizacioacuten

bull La administracioacuten tiene un mayor control se estandarizan e identifican los

procedimientos y los cambios resultan maacutes faacuteciles de manejar

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

manera maacutes adecuada los servicios de outsourcing

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 4

bull A traveacutes de las mejores praacutecticas de ITIL se apoya al cambio en la cultura de

TI y su orientacioacuten hacia el servicio y se facilita la introduccioacuten de un sistema

de administracioacuten de calidad

bull ITIL proporciona un marco de referencia uniforme para la comunicacioacuten

interna y con proveedores

Desventajas

bull Tiempo y esfuerzo necesario para su implementacioacuten

bull Que no se deacute el cambio en la cultura de las aacutereas involucradas

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

procesos indicadores y como pueden ser controlados

bull Que el personal no se involucre y se comprometa

bull La mejora del servicio y la reduccioacuten de costos puede no ser visible

bull Que la inversioacuten en herramientas de soporte sea escasa Los procesos

podraacuten parecer inuacutetiles y no se alcancen las mejoras en los servicios

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

Tecnologiacutea ITIL

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 5

Figura 1 ITIL en Managed Services

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

Seguacuten la Figura 2 vemos como aparentemente tenemos segmentos del

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

de las soluciones Por ejemplo la prestacioacuten de servicios muchas veces no

seriacutea posible sin la gestioacuten de infraestructura asimismo las perspectivas del

negocio no se dariacutean sin la prestacioacuten de servicio y los servicios no serian

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

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

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

prestacioacuten de servicios la prestacioacuten de servicios requiere que se le de un

soporte al servicio para que este siempre disponible la disponibilidad la

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

al centro las soluciones vamos a tener a los clientes satisfechos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 6

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

interaccioacuten que se da entre las diferentes aacutereas de un negocio es la buacutesqueda

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

esteacuten soportadas entre siacute por medio del sistema1

Figura2 Soluciones para ITIL desde el punto de vista de negocio

14 Certificacioacuten

Los particulares pueden conseguir varias certificaciones oficiales ITIL Los

estaacutendares de calificacioacuten 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 Paiacuteses Bajos) e

ISEB (con sede en el Reino Unido)

Existen tres niveles de certificacioacuten ITIL para profesionales

1 Foundation Certificate (Certificado Baacutesico) acredita un conocimiento

baacutesico de ITIL en gestioacuten de servicios de tecnologiacuteas de la informacioacuten y

1 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtml

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 7

la comprensioacuten de la terminologiacutea propia de ITIL Estaacute destinado a

aquellas personas que deseen conocer las buenas praacutecticas

especificadas en ITIL

2 Practitioners Certificate (Certificado de Responsable) destinado a

quienes tienen responsabilidad en el disentildeo de procesos de

administracioacuten de departamentos de tecnologiacuteas de la informacioacuten y en

la planificacioacuten de las actividades asociadas a los procesos

3 Managers Certificate (Certificado de Director) garantiza que quien lo

posee dispone de profundos conocimientos en todas las materias

relacionadas con la administracioacuten de departamentos de tecnologiacuteas de

la informacioacuten y lo habilita para dirigir la implantacioacuten de soluciones

basadas en ITIL

No es posible certificar una organizacioacuten o sistema de gestioacuten como laquoconforme

a ITILraquo pero una organizacioacuten que haya implementado las guiacuteas de ITIL sobre

Gestioacuten de los Servicios de TI puede lograr certificarse bajo la ISOIEC 200002

La versioacuten 3 de ITIL que aparecioacute en junio de 2007 cambioacute 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)

15 Historia y precursores de ITIL

Lo que actualmente se conoce como ITIL versioacuten 1 desarrollada bajo el

auspicio de la CCTA se tituloacute Government Information Technology

Infrastructure Method (lsquoMeacutetodo de Infraestructura de la Tecnologiacutea de 2 httpeswikipediaorgwikiInformation_Technology_Infrastructure_Library

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 8

Informacioacuten del Gobiernorsquo GITM) y durante varios antildeos terminoacute expandieacutendose

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 guiacutea y no como un meacutetodo formal y como resultado del creciente

intereacutes que habiacutea fuera del gobierno britaacutenico

Muchos de los conceptos principales de gestioacuten 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 lsquoUn

sistema de gestioacuten para el negocio de la informacioacutenrsquo)[4] [5] fueron precursores

claves Seguacuten IBM

A principios de los antildeos 1980 IBM documentoacute los conceptos originales de

Gestioacuten de Sistemas en una serie de cuatro voluacutemenes 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 tomoacute prestado de ellos hasta

tales extremos

16 Criacuteticas a ITIL

ITIL ha recibido criacuteticas de varios frentes Entre ellas

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

marco holiacutestico y completo para el gobierno de TI

Su tendencia a convertirla en una religioacuten

Como sentildeala Jan van Bon (autor y editor de muchas publicaciones de Gestioacuten

de Servicios de TI)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 9

Hay mucha confusioacuten sobre ITIL procedente de todo tipo de malentendidos

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

praacutecticas La OGC no afirma que dichas mejoras praacutecticas describan procesos

puros ni tampoco que ITIL sea un marco disentildeado como un modelo coherente

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

tienen una gran necesidad de dicho modelo 3

El columnista CIO Magazine Dean Meyer tambieacuten ha expuesto algunos puntos

de vista cautelosos sobre ITIL incluyendo cinco trampas tiacutepicas tales como

laquoconvertirse en esclavo de definiciones desactualizadasraquo y laquodejar que ITIL se

convierta en religioacutenraquo Como Meyer sentildeala ITIL laquono describe el abanico

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

servicios actualesraquo4

La calidad de los voluacutemenes de la biblioteca se considera desigual Por

ejemplo Van Herwaarden y Grift sentildealan que laquola consistencia que

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

en los libros de entrega de servicioraquo5

17 Forma de uso de ITIL en Managed Services

ITIL postula que el servicio de soporte la administracioacuten y la operacioacuten se

realiza a traveacutes 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 Gestioacuten de Servicios de TI)

4 CIO Magazine Dean Meyer

5 Van Herwaarden y Grift

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 10

171 PROCESO DE MANEJO DE INCIDENTES

Su objetivo primordial es restablecer el servicio lo maacutes raacutepido posible para

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

minimicen los efectos de la operacioacuten Se dice que el proveedor de debe de

encargar de que el cliente no debe percibir todas aquellas pequentildeas 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 baacutesicos que son propiedad monitoreo manejo de secuencias y

comunicacioacuten

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

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

anomaliacutea 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 clasificacioacuten 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 seguacuten el manual de procedimientos para poder llegar a la

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

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

documentacioacuten y contabilizacioacuten del incidente para ver queacute tanta incidencia

tiene este caso finalmente se hace una evaluacioacuten para ver si efectivamente

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

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

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

se recurre a hacer una investigacioacuten y un diagnostico de la situacioacuten para ver

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

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 11

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

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

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

peo cuando el nivel de dantildeo es muy fuerte se da el caso de que se deacute por

perdido) y finamente se cierra el incidente y esta solucioacuten se documenta en

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

Data Base (aquiacute 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 maacutes faacutecil raacutepida y eficiente su resolucioacuten6

Figura 3 Proceso de manejo de incidentes

172 PROCESO DE MANEJO DE PROBLEMAS

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

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

6 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtml

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 12

ayuda a proporcionar soluciones raacutepidas 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 daacutendole 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 estaacute relacionada con lo que es el control del problema y la segunda

es con el control del error7

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

identificar el problema en base a alguna sintomatologiacutea ya que tenemos este

antecedente pasamos a la clasificacioacuten 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

estaacuten en el manual de procedimientos y en caso de no ser conocido se tendriacutea

que hacer una fase de investigacioacuten para ver queacute es lo que genera el problema

y maacutes tarde hacer un diagnostico ya que tenemos un diagnoacutestico 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 solucioacuten

y finalmente se va a hacer una evaluacioacuten para ver si se resolvioacute el problema

de raiacutez En caso de que si se funcione esta solucioacuten se pasa a la

documentacioacuten

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

por medio de una identificacioacuten 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 clasificacioacuten y se recurre a una evaluacioacuten de que tanto dantildeo genero

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

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

no se solucione posteriormente se hace la resolucioacuten o correccioacuten del error

7 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 13

(este puede deberse a varios aspectos configuraciones falta de seguridad

inconsistencia de datos etc) y este modelo tiene una fase muy difiacutecil que es

determinar que problemas estaacuten 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 pasariacutea si

cambio algunos de los datos en la configuracioacuten del sistema se tendriacutea que

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

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

Figura 4 Proceso de manejo de problemas

173 PROCESO DE MANEJO DE CONFIGURACIONES

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

configurado e instalado en cada sistema del cliente

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

mueve bajo cuatro veacutertices que son administracioacuten de cambios administracioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 14

de liberaciones administracioacuten de configuraciones y la administracioacuten de

procesos diversos8

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

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

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

manipular Aunque es lo maacutes parecido a la realidad porque nuestro entorno es

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

respecta a la administracioacuten de cambios vemos que se relaciona directamente

con la administracioacuten de incidentes y de problemas lo que conlleva una

planeacioacuten identificacioacuten control seguimiento del status verificacioacuten y

auditoria de configuraciones lo que hace que haya muchas variables

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

la liberacioacuten y distribucioacuten de nuevas versiones esto de da por una fase de

planeacioacuten identificacioacuten control revisioacuten del status verificacioacuten y auditoria y

puede depender de la administracioacuten de las capacidades ya que si no se

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

asiacute se hariacutea con todos los niveles hasta llegar al cierre del control de cambios

8 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 15

Figura 5 Proceso de manejo de configuraciones

174 PROCESO DE CONTROL DE CAMBIOS

El objetivo de este proceso es reducir los riesgos tanto teacutecnicos econoacutemicos y

de tiempo al momento de la realizacioacuten de los cambios

La Figura 6 al parecer es muy faacutecil 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 objetivos9

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

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

9 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 16

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

sea malo se pasa a la fase de reingenieriacutea 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 estaacute

probado se da la autorizacioacuten e implementacioacuten ya implementado se ve que no

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

tambieacuten se le considera como revisioacuten post-implementacioacuten

Figura 6 Proceso de control de cambios

175 PROCESO DE MANEJO DE ENTREGAS

Su objetivo es planear y controlar exitosamente la instalacioacuten 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 transicioacuten que se da de acuerdo

a los ambientes por los que se va dando la evolucioacuten del proyecto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 17

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

que hacer la liberacioacuten de las poliacuteticas la liberacioacuten de la planeacioacuten el disentildeo

loacutegico de la infraestructura que se va a implementar y la adquisicioacuten de

software y hardware estaacuten 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 construccioacuten y

liberacioacuten de las configuraciones (nivel loacutegico) se hacen las pruebas para

establecer los acuerdos de aceptacioacuten se da la aceptacioacuten total de versiones y

de modelos se arranca la planeacioacuten y finalmente las pruebas y

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

distribucioacuten e instalacioacuten 10

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

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

instalacioacuten

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

del servicio y no sabe que detraacutes del servicio que estaacute 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 maacutes 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 planeacioacuten monitoreo anaacutelisis y por un sin fin de pruebas con la intencioacuten

de que en caso de que algo no funcione se deacute en la fase de pruebas

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

afectado es el cliente

10

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 18

Figura 7 Proceso de manejo de entregas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 19

CAPITULO II

GESTION DE VERSIONES

21 Introduccioacuten y Objetivos

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

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

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

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

configuracioacuten de la infraestructura TI

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

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

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten 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 implementacioacuten de cualquier

cambio

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

proceso pero es tarea especiacutefica de la Gestioacuten de Versiones el disentildear poner a

prueba e instalar en el entorno de produccioacuten los cambios preestablecidos

Todo ello requiere de una cuidadosa planificacioacuten y coordinacioacuten con el resto

de procesos asociados a la Gestioacuten de Servicios TI

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 20

Entre los principales objetivos de la Gestioacuten de Versiones se incluyen

Establecer una poliacutetica de implementacioacuten de nuevas versiones de

hardware y software

Implementar las nuevas versiones de software y hardware en el entorno

de produccioacuten tras su verificacioacuten en un entorno realista de pruebas

Garantizar que el proceso de cambio cumpla las especificaciones de la

RFC correspondiente

Asegurar en colaboracioacuten con la Gestioacuten de Cambios y

Configuraciones que todos los cambios se ven correctamente reflejados

en la CMDB

Archivar copias ideacutenticas del software en produccioacuten asiacute como de toda

su documentacioacuten asociada en la Biblioteca de Software Definitivo

(DSL)

Mantener actualizado el Depoacutesito de Hardware Definitivo (DHS)

22 Beneficios y Dificultades

Los beneficios de una correcta Gestioacuten 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 nuacutemero de incidentes por incompatibilidades con otro

software o hardware instalado

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

software y hardware a instalar sino que tambieacuten permite conocer la

opinioacuten 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 nuacutemero de copias de software ilegales

Control centralizado del software y hardware desplegado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 21

Proteccioacuten contra virus y problemas asociados a versiones de software

incontroladas

Las principales dificultades con las que topa la Gestioacuten de Versiones son

No existe una clara asignacioacuten de responsabilidades yo la organizacioacuten

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

proceso de implementacioacuten 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 centralizacioacuten del

proceso de cambio Es habitual que existan reticencias a adoptar

sistemas estandarizados en toda la organizacioacuten sobre todo cuando

eacutesta no ha sido la poliacutetica tradicional de la misma

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

argumentado que estos soacutelo son responsabilidad de un determinado

grupo de trabajo o que su urgencia requeriacutea de ello

Hay resistencias a aceptar posibles planes de back-out Ciertos

entornos de produccioacuten pueden elegir ignorar lo problemas que una

nueva versioacuten puede provocar en otras aacutereas y resistirse a volver a la

uacuteltima versioacuten estable

La implementacioacuten sincronizada de versiones en entornos altamente

distribuidos

La solucioacuten a estos problemas pasa por

Un firme compromiso de la organizacioacuten con la Gestioacuten de Versiones y

sus responsables

Un adecuado plan de comunicacioacuten que informe a todos los

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

correcta gestioacuten de todo el proceso de cambio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 22

Una versioacuten es un grupo de CIs de nueva creacioacuten o modificados que han sido

validados para su instalacioacuten en el entorno de produccioacuten Las especificaciones

funcionales y teacutecnicas de una versioacuten estaacuten determinadas en la RFC

correspondiente

23 Clasificacioacuten de las Versiones

Las versiones pueden clasificarse seguacuten 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 caracteriacutesticas teacutecnicas etc

Versiones menores que suelen implicar la correccioacuten 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 raacutepida

un error conocido

Como pueden llegar a existir muacuteltiples versiones es conveniente definir una

referencia o coacutedigo que los identifique uniacutevocamente El sistema

universalmente aceptado es

Versiones mayores 10 20 etc

Versiones menores 11 12 13 etc

Versiones de emergencia 111 112 etc

Aunque en algunos casos esta clasificacioacuten se refina auacuten maacutes (vea por

ejemplo en la ayuda la versioacuten de su navegador)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 23

En su ciclo de vida una versioacuten puede encontrase en diversos estados

desarrollo pruebas produccioacuten y archivado11

En la Figura 8 nos ilustra graacuteficamente la evolucioacuten temporal de una versioacuten

Figura 8 Evolucioacuten temporal de una versioacuten

El despliegue de nuevas versiones puede realizarse de diferentes maneras y

es responsabilidad de la Gestioacuten de Cambios el determinar la forma maacutes

conveniente de hacerlo Entre las opciones maacutes habituales cabe contar

Versioacuten delta soacutelo se testean e instalan los elementos modificados

Esta opcioacuten tiene como ventaja su mayor simplicidad pero conlleva el

peligro de que puedan aparecer problemas e incompatibilidades en el

entorno de produccioacuten

Versioacuten completa Se distribuyen todos los elementos afectados ya

hayan sido modificados o no Aunque esta opcioacuten es obviamente maacutes

trabajosa es maacutes improbable que se generen incidentes tras la

instalacioacuten si se han realizado las pruebas pertinentes

11

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 24

Paquete de Versiones La Gestioacuten 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 opcioacuten es obligada por incompatibilidades entre una nueva

versioacuten con software o hardware previamente instalado Pensemos por

ejemplo en la migracioacuten a un nuevo sistema operativo que requiere

hardware maacutes avanzado yo nuevos versiones de los programas

ofimaacuteticos

24 Visioacuten General

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

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

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

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

configuracioacuten de la infraestructura TI12

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

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

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten de Versiones se resumen

sucintamente en la siguiente Figura 9

12

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 25

Figura 9 Visioacuten General de la Gestioacuten de Versiones

25 Planificacioacuten

Es crucial establecer un marco general para el lanzamiento de nuevas

versiones que fije una metodologiacutea 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

especiacuteficos que tomen en cuenta las peculiaridades de cada caso

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

deben de tomar en cuenta los siguientes factores

Coacutemo puede afectar la nueva versioacuten a otras aacutereas del entramado TI

Queacute CIs se veraacuten directa o indirectamente implicados durante y tras el

lanzamiento de la nueva versioacuten

Coacutemo ha de construirse el entorno de pruebas para que eacuteste sea fiel

reflejo del entorno de produccioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 26

Queacute planes de back-out son necesarios

Coacutemo y cuaacutendo se deben implementar los planes de back-out para

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

sistema TI

Cuaacuteles son los recursos humanos y teacutecnicos necesarios para llevar a

cabo la implementacioacuten de la nueva versioacuten con garantiacuteas de eacutexito

Quieacutenes seraacuten los responsables directos en las diferentes etapas del

proceso

Queacute planes de comunicacioacuten yo formacioacuten deben desarrollarse para

que los usuarios esteacuten puntualmente informados y puedan percibir la

nueva versioacuten como una mejora

Queacute tipo de despliegue es el maacutes adecuado completo delta

sincronizado en todas los emplazamientos gradual

Cuaacutel es la vida media uacutetil esperada de la nueva versioacuten

Queacute impacto puede tener el proceso de lanzamiento de la nueva versioacuten

en la calidad del servicio

Si es posible establecer meacutetricas precisas que determinen el grado de

eacutexito del lanzamiento de la nueva versioacuten

26 Desarrollo

La Gestioacuten de Versiones es la encargada del disentildeo y construccioacuten de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes

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

participacioacuten de proveedores externos En este segundo caso la tarea de la

Gestioacuten de Versiones seraacute la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC Asimismo la Gestioacuten de Versiones seraacute la responsable de todo el

proceso de configuracioacuten necesario

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

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

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

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

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

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

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

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

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

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

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

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

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

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

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

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

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

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

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

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

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

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

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

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

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

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

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

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

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

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

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

de impedir que otro usuario pueda modificar dicho elemento

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

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

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

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

los planes de back-out14

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

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

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

CIs (Configuration Items) en el entorno de produccioacuten

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

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

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

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

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

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

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

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

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

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

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

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

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

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

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

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

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

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

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

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

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

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

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

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

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

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

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

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

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

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

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

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

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

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

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

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

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

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

cliente servidor

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

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

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

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

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

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

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

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

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

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

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

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

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

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

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

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

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

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

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

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

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

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

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

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

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

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

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

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

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

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

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

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

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

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

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

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

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

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

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

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

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

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

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

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

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

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

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

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

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

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

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

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

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

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

podemos hacer un branching retroactivo pero hacer un branching retroactivo

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

trabajar en otra rama

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

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

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

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

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

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

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

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

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

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

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

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

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

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

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

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

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

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

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

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

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

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

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

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 2: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 2

fundamentales de la Administracioacuten de Servicio IT Esta adopcioacuten y adaptacioacuten

de ITIL refleja la filosofiacutea de ITIL y es un desarrollo bienvenido ya que la ITIL

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

medio heterogeacuteneo y dividido de IT

ITIL fue desarrollada al reconocer que las organizaciones dependen cada vez

maacutes 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 comuacuten para todas las actividades del departamento IT

como parte de la provisioacuten de servicios basado en la infraestructura IT Estas

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

Administracioacuten de Servicio IT maacutes madura Cada uno de estos procesos cubre

una o maacutes tareas del departamento IT tal como desarrollo de servicio

administracioacuten de infraestructura y provisioacuten y soporte de los servicios Este

planteo del proceso permite describir las mejores praacutecticas de la Administracioacuten

de Servicio IT independientemente de la estructura de organizacioacuten real de la

entidad

12 El objetivo de usar ITIL en Managed Services

ITIL como metodologiacutea propone el establecimiento de estaacutendares que nos

ayuden en el control operacioacuten y administracioacuten de los recursos (ya sean

propios o de los clientes) Plantea hacer una revisioacuten y reestructuracioacuten de los

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

es bajo o que haya una forma maacutes 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 documentacioacuten pertinente ya que esta puede ser de gran

utilidad para otros miembros del aacuterea ademaacutes de que quedan asentados todos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 3

los movimientos realizados permitiendo que toda la gente esteacute al tanto de los

cambios y no se tome a nadie por sorpresa

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

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

cambio asiacute como quien es el que autorizo el cambio para que asiacute se lleve todo

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

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

y asiacute 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

bull Mejora la comunicacioacuten con los clientes y usuarios finales a traveacutes de los

diversos puntos de contacto acordados

bull Los servicios se detallan en lenguaje del cliente y con maacutes detalles

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

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

calidad de los mismos y relacioacuten entre el cliente y el departamento de IT

bull Una mayor flexibilidad y adaptabilidad de los servicios

Ventajas de ITIL para TI

bull La organizacioacuten TI desarrolla una estructura maacutes clara se vuelve maacutes eficaz

y se centra maacutes en los objetivos de la organizacioacuten

bull La administracioacuten tiene un mayor control se estandarizan e identifican los

procedimientos y los cambios resultan maacutes faacuteciles de manejar

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

manera maacutes adecuada los servicios de outsourcing

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 4

bull A traveacutes de las mejores praacutecticas de ITIL se apoya al cambio en la cultura de

TI y su orientacioacuten hacia el servicio y se facilita la introduccioacuten de un sistema

de administracioacuten de calidad

bull ITIL proporciona un marco de referencia uniforme para la comunicacioacuten

interna y con proveedores

Desventajas

bull Tiempo y esfuerzo necesario para su implementacioacuten

bull Que no se deacute el cambio en la cultura de las aacutereas involucradas

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

procesos indicadores y como pueden ser controlados

bull Que el personal no se involucre y se comprometa

bull La mejora del servicio y la reduccioacuten de costos puede no ser visible

bull Que la inversioacuten en herramientas de soporte sea escasa Los procesos

podraacuten parecer inuacutetiles y no se alcancen las mejoras en los servicios

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

Tecnologiacutea ITIL

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 5

Figura 1 ITIL en Managed Services

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

Seguacuten la Figura 2 vemos como aparentemente tenemos segmentos del

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

de las soluciones Por ejemplo la prestacioacuten de servicios muchas veces no

seriacutea posible sin la gestioacuten de infraestructura asimismo las perspectivas del

negocio no se dariacutean sin la prestacioacuten de servicio y los servicios no serian

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

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

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

prestacioacuten de servicios la prestacioacuten de servicios requiere que se le de un

soporte al servicio para que este siempre disponible la disponibilidad la

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

al centro las soluciones vamos a tener a los clientes satisfechos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 6

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

interaccioacuten que se da entre las diferentes aacutereas de un negocio es la buacutesqueda

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

esteacuten soportadas entre siacute por medio del sistema1

Figura2 Soluciones para ITIL desde el punto de vista de negocio

14 Certificacioacuten

Los particulares pueden conseguir varias certificaciones oficiales ITIL Los

estaacutendares de calificacioacuten 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 Paiacuteses Bajos) e

ISEB (con sede en el Reino Unido)

Existen tres niveles de certificacioacuten ITIL para profesionales

1 Foundation Certificate (Certificado Baacutesico) acredita un conocimiento

baacutesico de ITIL en gestioacuten de servicios de tecnologiacuteas de la informacioacuten y

1 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtml

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 7

la comprensioacuten de la terminologiacutea propia de ITIL Estaacute destinado a

aquellas personas que deseen conocer las buenas praacutecticas

especificadas en ITIL

2 Practitioners Certificate (Certificado de Responsable) destinado a

quienes tienen responsabilidad en el disentildeo de procesos de

administracioacuten de departamentos de tecnologiacuteas de la informacioacuten y en

la planificacioacuten de las actividades asociadas a los procesos

3 Managers Certificate (Certificado de Director) garantiza que quien lo

posee dispone de profundos conocimientos en todas las materias

relacionadas con la administracioacuten de departamentos de tecnologiacuteas de

la informacioacuten y lo habilita para dirigir la implantacioacuten de soluciones

basadas en ITIL

No es posible certificar una organizacioacuten o sistema de gestioacuten como laquoconforme

a ITILraquo pero una organizacioacuten que haya implementado las guiacuteas de ITIL sobre

Gestioacuten de los Servicios de TI puede lograr certificarse bajo la ISOIEC 200002

La versioacuten 3 de ITIL que aparecioacute en junio de 2007 cambioacute 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)

15 Historia y precursores de ITIL

Lo que actualmente se conoce como ITIL versioacuten 1 desarrollada bajo el

auspicio de la CCTA se tituloacute Government Information Technology

Infrastructure Method (lsquoMeacutetodo de Infraestructura de la Tecnologiacutea de 2 httpeswikipediaorgwikiInformation_Technology_Infrastructure_Library

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 8

Informacioacuten del Gobiernorsquo GITM) y durante varios antildeos terminoacute expandieacutendose

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 guiacutea y no como un meacutetodo formal y como resultado del creciente

intereacutes que habiacutea fuera del gobierno britaacutenico

Muchos de los conceptos principales de gestioacuten 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 lsquoUn

sistema de gestioacuten para el negocio de la informacioacutenrsquo)[4] [5] fueron precursores

claves Seguacuten IBM

A principios de los antildeos 1980 IBM documentoacute los conceptos originales de

Gestioacuten de Sistemas en una serie de cuatro voluacutemenes 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 tomoacute prestado de ellos hasta

tales extremos

16 Criacuteticas a ITIL

ITIL ha recibido criacuteticas de varios frentes Entre ellas

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

marco holiacutestico y completo para el gobierno de TI

Su tendencia a convertirla en una religioacuten

Como sentildeala Jan van Bon (autor y editor de muchas publicaciones de Gestioacuten

de Servicios de TI)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 9

Hay mucha confusioacuten sobre ITIL procedente de todo tipo de malentendidos

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

praacutecticas La OGC no afirma que dichas mejoras praacutecticas describan procesos

puros ni tampoco que ITIL sea un marco disentildeado como un modelo coherente

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

tienen una gran necesidad de dicho modelo 3

El columnista CIO Magazine Dean Meyer tambieacuten ha expuesto algunos puntos

de vista cautelosos sobre ITIL incluyendo cinco trampas tiacutepicas tales como

laquoconvertirse en esclavo de definiciones desactualizadasraquo y laquodejar que ITIL se

convierta en religioacutenraquo Como Meyer sentildeala ITIL laquono describe el abanico

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

servicios actualesraquo4

La calidad de los voluacutemenes de la biblioteca se considera desigual Por

ejemplo Van Herwaarden y Grift sentildealan que laquola consistencia que

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

en los libros de entrega de servicioraquo5

17 Forma de uso de ITIL en Managed Services

ITIL postula que el servicio de soporte la administracioacuten y la operacioacuten se

realiza a traveacutes 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 Gestioacuten de Servicios de TI)

4 CIO Magazine Dean Meyer

5 Van Herwaarden y Grift

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 10

171 PROCESO DE MANEJO DE INCIDENTES

Su objetivo primordial es restablecer el servicio lo maacutes raacutepido posible para

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

minimicen los efectos de la operacioacuten Se dice que el proveedor de debe de

encargar de que el cliente no debe percibir todas aquellas pequentildeas 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 baacutesicos que son propiedad monitoreo manejo de secuencias y

comunicacioacuten

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

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

anomaliacutea 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 clasificacioacuten 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 seguacuten el manual de procedimientos para poder llegar a la

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

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

documentacioacuten y contabilizacioacuten del incidente para ver queacute tanta incidencia

tiene este caso finalmente se hace una evaluacioacuten para ver si efectivamente

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

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

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

se recurre a hacer una investigacioacuten y un diagnostico de la situacioacuten para ver

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

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 11

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

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

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

peo cuando el nivel de dantildeo es muy fuerte se da el caso de que se deacute por

perdido) y finamente se cierra el incidente y esta solucioacuten se documenta en

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

Data Base (aquiacute 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 maacutes faacutecil raacutepida y eficiente su resolucioacuten6

Figura 3 Proceso de manejo de incidentes

172 PROCESO DE MANEJO DE PROBLEMAS

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

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

6 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtml

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 12

ayuda a proporcionar soluciones raacutepidas 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 daacutendole 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 estaacute relacionada con lo que es el control del problema y la segunda

es con el control del error7

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

identificar el problema en base a alguna sintomatologiacutea ya que tenemos este

antecedente pasamos a la clasificacioacuten 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

estaacuten en el manual de procedimientos y en caso de no ser conocido se tendriacutea

que hacer una fase de investigacioacuten para ver queacute es lo que genera el problema

y maacutes tarde hacer un diagnostico ya que tenemos un diagnoacutestico 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 solucioacuten

y finalmente se va a hacer una evaluacioacuten para ver si se resolvioacute el problema

de raiacutez En caso de que si se funcione esta solucioacuten se pasa a la

documentacioacuten

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

por medio de una identificacioacuten 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 clasificacioacuten y se recurre a una evaluacioacuten de que tanto dantildeo genero

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

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

no se solucione posteriormente se hace la resolucioacuten o correccioacuten del error

7 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 13

(este puede deberse a varios aspectos configuraciones falta de seguridad

inconsistencia de datos etc) y este modelo tiene una fase muy difiacutecil que es

determinar que problemas estaacuten 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 pasariacutea si

cambio algunos de los datos en la configuracioacuten del sistema se tendriacutea que

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

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

Figura 4 Proceso de manejo de problemas

173 PROCESO DE MANEJO DE CONFIGURACIONES

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

configurado e instalado en cada sistema del cliente

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

mueve bajo cuatro veacutertices que son administracioacuten de cambios administracioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 14

de liberaciones administracioacuten de configuraciones y la administracioacuten de

procesos diversos8

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

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

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

manipular Aunque es lo maacutes parecido a la realidad porque nuestro entorno es

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

respecta a la administracioacuten de cambios vemos que se relaciona directamente

con la administracioacuten de incidentes y de problemas lo que conlleva una

planeacioacuten identificacioacuten control seguimiento del status verificacioacuten y

auditoria de configuraciones lo que hace que haya muchas variables

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

la liberacioacuten y distribucioacuten de nuevas versiones esto de da por una fase de

planeacioacuten identificacioacuten control revisioacuten del status verificacioacuten y auditoria y

puede depender de la administracioacuten de las capacidades ya que si no se

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

asiacute se hariacutea con todos los niveles hasta llegar al cierre del control de cambios

8 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 15

Figura 5 Proceso de manejo de configuraciones

174 PROCESO DE CONTROL DE CAMBIOS

El objetivo de este proceso es reducir los riesgos tanto teacutecnicos econoacutemicos y

de tiempo al momento de la realizacioacuten de los cambios

La Figura 6 al parecer es muy faacutecil 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 objetivos9

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

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

9 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 16

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

sea malo se pasa a la fase de reingenieriacutea 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 estaacute

probado se da la autorizacioacuten e implementacioacuten ya implementado se ve que no

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

tambieacuten se le considera como revisioacuten post-implementacioacuten

Figura 6 Proceso de control de cambios

175 PROCESO DE MANEJO DE ENTREGAS

Su objetivo es planear y controlar exitosamente la instalacioacuten 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 transicioacuten que se da de acuerdo

a los ambientes por los que se va dando la evolucioacuten del proyecto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 17

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

que hacer la liberacioacuten de las poliacuteticas la liberacioacuten de la planeacioacuten el disentildeo

loacutegico de la infraestructura que se va a implementar y la adquisicioacuten de

software y hardware estaacuten 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 construccioacuten y

liberacioacuten de las configuraciones (nivel loacutegico) se hacen las pruebas para

establecer los acuerdos de aceptacioacuten se da la aceptacioacuten total de versiones y

de modelos se arranca la planeacioacuten y finalmente las pruebas y

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

distribucioacuten e instalacioacuten 10

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

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

instalacioacuten

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

del servicio y no sabe que detraacutes del servicio que estaacute 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 maacutes 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 planeacioacuten monitoreo anaacutelisis y por un sin fin de pruebas con la intencioacuten

de que en caso de que algo no funcione se deacute en la fase de pruebas

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

afectado es el cliente

10

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 18

Figura 7 Proceso de manejo de entregas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 19

CAPITULO II

GESTION DE VERSIONES

21 Introduccioacuten y Objetivos

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

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

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

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

configuracioacuten de la infraestructura TI

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

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

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten 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 implementacioacuten de cualquier

cambio

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

proceso pero es tarea especiacutefica de la Gestioacuten de Versiones el disentildear poner a

prueba e instalar en el entorno de produccioacuten los cambios preestablecidos

Todo ello requiere de una cuidadosa planificacioacuten y coordinacioacuten con el resto

de procesos asociados a la Gestioacuten de Servicios TI

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 20

Entre los principales objetivos de la Gestioacuten de Versiones se incluyen

Establecer una poliacutetica de implementacioacuten de nuevas versiones de

hardware y software

Implementar las nuevas versiones de software y hardware en el entorno

de produccioacuten tras su verificacioacuten en un entorno realista de pruebas

Garantizar que el proceso de cambio cumpla las especificaciones de la

RFC correspondiente

Asegurar en colaboracioacuten con la Gestioacuten de Cambios y

Configuraciones que todos los cambios se ven correctamente reflejados

en la CMDB

Archivar copias ideacutenticas del software en produccioacuten asiacute como de toda

su documentacioacuten asociada en la Biblioteca de Software Definitivo

(DSL)

Mantener actualizado el Depoacutesito de Hardware Definitivo (DHS)

22 Beneficios y Dificultades

Los beneficios de una correcta Gestioacuten 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 nuacutemero de incidentes por incompatibilidades con otro

software o hardware instalado

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

software y hardware a instalar sino que tambieacuten permite conocer la

opinioacuten 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 nuacutemero de copias de software ilegales

Control centralizado del software y hardware desplegado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 21

Proteccioacuten contra virus y problemas asociados a versiones de software

incontroladas

Las principales dificultades con las que topa la Gestioacuten de Versiones son

No existe una clara asignacioacuten de responsabilidades yo la organizacioacuten

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

proceso de implementacioacuten 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 centralizacioacuten del

proceso de cambio Es habitual que existan reticencias a adoptar

sistemas estandarizados en toda la organizacioacuten sobre todo cuando

eacutesta no ha sido la poliacutetica tradicional de la misma

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

argumentado que estos soacutelo son responsabilidad de un determinado

grupo de trabajo o que su urgencia requeriacutea de ello

Hay resistencias a aceptar posibles planes de back-out Ciertos

entornos de produccioacuten pueden elegir ignorar lo problemas que una

nueva versioacuten puede provocar en otras aacutereas y resistirse a volver a la

uacuteltima versioacuten estable

La implementacioacuten sincronizada de versiones en entornos altamente

distribuidos

La solucioacuten a estos problemas pasa por

Un firme compromiso de la organizacioacuten con la Gestioacuten de Versiones y

sus responsables

Un adecuado plan de comunicacioacuten que informe a todos los

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

correcta gestioacuten de todo el proceso de cambio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 22

Una versioacuten es un grupo de CIs de nueva creacioacuten o modificados que han sido

validados para su instalacioacuten en el entorno de produccioacuten Las especificaciones

funcionales y teacutecnicas de una versioacuten estaacuten determinadas en la RFC

correspondiente

23 Clasificacioacuten de las Versiones

Las versiones pueden clasificarse seguacuten 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 caracteriacutesticas teacutecnicas etc

Versiones menores que suelen implicar la correccioacuten 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 raacutepida

un error conocido

Como pueden llegar a existir muacuteltiples versiones es conveniente definir una

referencia o coacutedigo que los identifique uniacutevocamente El sistema

universalmente aceptado es

Versiones mayores 10 20 etc

Versiones menores 11 12 13 etc

Versiones de emergencia 111 112 etc

Aunque en algunos casos esta clasificacioacuten se refina auacuten maacutes (vea por

ejemplo en la ayuda la versioacuten de su navegador)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 23

En su ciclo de vida una versioacuten puede encontrase en diversos estados

desarrollo pruebas produccioacuten y archivado11

En la Figura 8 nos ilustra graacuteficamente la evolucioacuten temporal de una versioacuten

Figura 8 Evolucioacuten temporal de una versioacuten

El despliegue de nuevas versiones puede realizarse de diferentes maneras y

es responsabilidad de la Gestioacuten de Cambios el determinar la forma maacutes

conveniente de hacerlo Entre las opciones maacutes habituales cabe contar

Versioacuten delta soacutelo se testean e instalan los elementos modificados

Esta opcioacuten tiene como ventaja su mayor simplicidad pero conlleva el

peligro de que puedan aparecer problemas e incompatibilidades en el

entorno de produccioacuten

Versioacuten completa Se distribuyen todos los elementos afectados ya

hayan sido modificados o no Aunque esta opcioacuten es obviamente maacutes

trabajosa es maacutes improbable que se generen incidentes tras la

instalacioacuten si se han realizado las pruebas pertinentes

11

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 24

Paquete de Versiones La Gestioacuten 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 opcioacuten es obligada por incompatibilidades entre una nueva

versioacuten con software o hardware previamente instalado Pensemos por

ejemplo en la migracioacuten a un nuevo sistema operativo que requiere

hardware maacutes avanzado yo nuevos versiones de los programas

ofimaacuteticos

24 Visioacuten General

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

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

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

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

configuracioacuten de la infraestructura TI12

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

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

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten de Versiones se resumen

sucintamente en la siguiente Figura 9

12

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 25

Figura 9 Visioacuten General de la Gestioacuten de Versiones

25 Planificacioacuten

Es crucial establecer un marco general para el lanzamiento de nuevas

versiones que fije una metodologiacutea 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

especiacuteficos que tomen en cuenta las peculiaridades de cada caso

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

deben de tomar en cuenta los siguientes factores

Coacutemo puede afectar la nueva versioacuten a otras aacutereas del entramado TI

Queacute CIs se veraacuten directa o indirectamente implicados durante y tras el

lanzamiento de la nueva versioacuten

Coacutemo ha de construirse el entorno de pruebas para que eacuteste sea fiel

reflejo del entorno de produccioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 26

Queacute planes de back-out son necesarios

Coacutemo y cuaacutendo se deben implementar los planes de back-out para

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

sistema TI

Cuaacuteles son los recursos humanos y teacutecnicos necesarios para llevar a

cabo la implementacioacuten de la nueva versioacuten con garantiacuteas de eacutexito

Quieacutenes seraacuten los responsables directos en las diferentes etapas del

proceso

Queacute planes de comunicacioacuten yo formacioacuten deben desarrollarse para

que los usuarios esteacuten puntualmente informados y puedan percibir la

nueva versioacuten como una mejora

Queacute tipo de despliegue es el maacutes adecuado completo delta

sincronizado en todas los emplazamientos gradual

Cuaacutel es la vida media uacutetil esperada de la nueva versioacuten

Queacute impacto puede tener el proceso de lanzamiento de la nueva versioacuten

en la calidad del servicio

Si es posible establecer meacutetricas precisas que determinen el grado de

eacutexito del lanzamiento de la nueva versioacuten

26 Desarrollo

La Gestioacuten de Versiones es la encargada del disentildeo y construccioacuten de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes

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

participacioacuten de proveedores externos En este segundo caso la tarea de la

Gestioacuten de Versiones seraacute la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC Asimismo la Gestioacuten de Versiones seraacute la responsable de todo el

proceso de configuracioacuten necesario

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

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

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

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

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

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

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

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

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

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

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

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

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

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

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

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

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

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

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

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

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

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

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

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

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

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

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

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

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

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

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

de impedir que otro usuario pueda modificar dicho elemento

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

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

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

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

los planes de back-out14

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

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

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

CIs (Configuration Items) en el entorno de produccioacuten

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

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

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

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

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

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

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

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

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

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

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

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

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

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

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

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

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

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

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

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

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

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

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

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

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

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

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

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

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

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

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

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

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

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

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

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

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

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

cliente servidor

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

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

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

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

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

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

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

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

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

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

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

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

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

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

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

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

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

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

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

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

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

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

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

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

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

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

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

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

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

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

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

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

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

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

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

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

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

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

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

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

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

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

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

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

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

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

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

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

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

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

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

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

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

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

podemos hacer un branching retroactivo pero hacer un branching retroactivo

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

trabajar en otra rama

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

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

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

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

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

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

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

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

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

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

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

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

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

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

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

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

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

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

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

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

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

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

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

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 3: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 3

los movimientos realizados permitiendo que toda la gente esteacute al tanto de los

cambios y no se tome a nadie por sorpresa

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

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

cambio asiacute como quien es el que autorizo el cambio para que asiacute se lleve todo

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

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

y asiacute 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

bull Mejora la comunicacioacuten con los clientes y usuarios finales a traveacutes de los

diversos puntos de contacto acordados

bull Los servicios se detallan en lenguaje del cliente y con maacutes detalles

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

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

calidad de los mismos y relacioacuten entre el cliente y el departamento de IT

bull Una mayor flexibilidad y adaptabilidad de los servicios

Ventajas de ITIL para TI

bull La organizacioacuten TI desarrolla una estructura maacutes clara se vuelve maacutes eficaz

y se centra maacutes en los objetivos de la organizacioacuten

bull La administracioacuten tiene un mayor control se estandarizan e identifican los

procedimientos y los cambios resultan maacutes faacuteciles de manejar

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

manera maacutes adecuada los servicios de outsourcing

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 4

bull A traveacutes de las mejores praacutecticas de ITIL se apoya al cambio en la cultura de

TI y su orientacioacuten hacia el servicio y se facilita la introduccioacuten de un sistema

de administracioacuten de calidad

bull ITIL proporciona un marco de referencia uniforme para la comunicacioacuten

interna y con proveedores

Desventajas

bull Tiempo y esfuerzo necesario para su implementacioacuten

bull Que no se deacute el cambio en la cultura de las aacutereas involucradas

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

procesos indicadores y como pueden ser controlados

bull Que el personal no se involucre y se comprometa

bull La mejora del servicio y la reduccioacuten de costos puede no ser visible

bull Que la inversioacuten en herramientas de soporte sea escasa Los procesos

podraacuten parecer inuacutetiles y no se alcancen las mejoras en los servicios

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

Tecnologiacutea ITIL

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 5

Figura 1 ITIL en Managed Services

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

Seguacuten la Figura 2 vemos como aparentemente tenemos segmentos del

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

de las soluciones Por ejemplo la prestacioacuten de servicios muchas veces no

seriacutea posible sin la gestioacuten de infraestructura asimismo las perspectivas del

negocio no se dariacutean sin la prestacioacuten de servicio y los servicios no serian

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

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

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

prestacioacuten de servicios la prestacioacuten de servicios requiere que se le de un

soporte al servicio para que este siempre disponible la disponibilidad la

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

al centro las soluciones vamos a tener a los clientes satisfechos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 6

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

interaccioacuten que se da entre las diferentes aacutereas de un negocio es la buacutesqueda

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

esteacuten soportadas entre siacute por medio del sistema1

Figura2 Soluciones para ITIL desde el punto de vista de negocio

14 Certificacioacuten

Los particulares pueden conseguir varias certificaciones oficiales ITIL Los

estaacutendares de calificacioacuten 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 Paiacuteses Bajos) e

ISEB (con sede en el Reino Unido)

Existen tres niveles de certificacioacuten ITIL para profesionales

1 Foundation Certificate (Certificado Baacutesico) acredita un conocimiento

baacutesico de ITIL en gestioacuten de servicios de tecnologiacuteas de la informacioacuten y

1 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtml

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 7

la comprensioacuten de la terminologiacutea propia de ITIL Estaacute destinado a

aquellas personas que deseen conocer las buenas praacutecticas

especificadas en ITIL

2 Practitioners Certificate (Certificado de Responsable) destinado a

quienes tienen responsabilidad en el disentildeo de procesos de

administracioacuten de departamentos de tecnologiacuteas de la informacioacuten y en

la planificacioacuten de las actividades asociadas a los procesos

3 Managers Certificate (Certificado de Director) garantiza que quien lo

posee dispone de profundos conocimientos en todas las materias

relacionadas con la administracioacuten de departamentos de tecnologiacuteas de

la informacioacuten y lo habilita para dirigir la implantacioacuten de soluciones

basadas en ITIL

No es posible certificar una organizacioacuten o sistema de gestioacuten como laquoconforme

a ITILraquo pero una organizacioacuten que haya implementado las guiacuteas de ITIL sobre

Gestioacuten de los Servicios de TI puede lograr certificarse bajo la ISOIEC 200002

La versioacuten 3 de ITIL que aparecioacute en junio de 2007 cambioacute 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)

15 Historia y precursores de ITIL

Lo que actualmente se conoce como ITIL versioacuten 1 desarrollada bajo el

auspicio de la CCTA se tituloacute Government Information Technology

Infrastructure Method (lsquoMeacutetodo de Infraestructura de la Tecnologiacutea de 2 httpeswikipediaorgwikiInformation_Technology_Infrastructure_Library

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 8

Informacioacuten del Gobiernorsquo GITM) y durante varios antildeos terminoacute expandieacutendose

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 guiacutea y no como un meacutetodo formal y como resultado del creciente

intereacutes que habiacutea fuera del gobierno britaacutenico

Muchos de los conceptos principales de gestioacuten 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 lsquoUn

sistema de gestioacuten para el negocio de la informacioacutenrsquo)[4] [5] fueron precursores

claves Seguacuten IBM

A principios de los antildeos 1980 IBM documentoacute los conceptos originales de

Gestioacuten de Sistemas en una serie de cuatro voluacutemenes 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 tomoacute prestado de ellos hasta

tales extremos

16 Criacuteticas a ITIL

ITIL ha recibido criacuteticas de varios frentes Entre ellas

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

marco holiacutestico y completo para el gobierno de TI

Su tendencia a convertirla en una religioacuten

Como sentildeala Jan van Bon (autor y editor de muchas publicaciones de Gestioacuten

de Servicios de TI)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 9

Hay mucha confusioacuten sobre ITIL procedente de todo tipo de malentendidos

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

praacutecticas La OGC no afirma que dichas mejoras praacutecticas describan procesos

puros ni tampoco que ITIL sea un marco disentildeado como un modelo coherente

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

tienen una gran necesidad de dicho modelo 3

El columnista CIO Magazine Dean Meyer tambieacuten ha expuesto algunos puntos

de vista cautelosos sobre ITIL incluyendo cinco trampas tiacutepicas tales como

laquoconvertirse en esclavo de definiciones desactualizadasraquo y laquodejar que ITIL se

convierta en religioacutenraquo Como Meyer sentildeala ITIL laquono describe el abanico

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

servicios actualesraquo4

La calidad de los voluacutemenes de la biblioteca se considera desigual Por

ejemplo Van Herwaarden y Grift sentildealan que laquola consistencia que

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

en los libros de entrega de servicioraquo5

17 Forma de uso de ITIL en Managed Services

ITIL postula que el servicio de soporte la administracioacuten y la operacioacuten se

realiza a traveacutes 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 Gestioacuten de Servicios de TI)

4 CIO Magazine Dean Meyer

5 Van Herwaarden y Grift

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 10

171 PROCESO DE MANEJO DE INCIDENTES

Su objetivo primordial es restablecer el servicio lo maacutes raacutepido posible para

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

minimicen los efectos de la operacioacuten Se dice que el proveedor de debe de

encargar de que el cliente no debe percibir todas aquellas pequentildeas 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 baacutesicos que son propiedad monitoreo manejo de secuencias y

comunicacioacuten

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

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

anomaliacutea 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 clasificacioacuten 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 seguacuten el manual de procedimientos para poder llegar a la

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

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

documentacioacuten y contabilizacioacuten del incidente para ver queacute tanta incidencia

tiene este caso finalmente se hace una evaluacioacuten para ver si efectivamente

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

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

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

se recurre a hacer una investigacioacuten y un diagnostico de la situacioacuten para ver

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

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 11

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

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

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

peo cuando el nivel de dantildeo es muy fuerte se da el caso de que se deacute por

perdido) y finamente se cierra el incidente y esta solucioacuten se documenta en

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

Data Base (aquiacute 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 maacutes faacutecil raacutepida y eficiente su resolucioacuten6

Figura 3 Proceso de manejo de incidentes

172 PROCESO DE MANEJO DE PROBLEMAS

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

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

6 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtml

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 12

ayuda a proporcionar soluciones raacutepidas 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 daacutendole 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 estaacute relacionada con lo que es el control del problema y la segunda

es con el control del error7

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

identificar el problema en base a alguna sintomatologiacutea ya que tenemos este

antecedente pasamos a la clasificacioacuten 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

estaacuten en el manual de procedimientos y en caso de no ser conocido se tendriacutea

que hacer una fase de investigacioacuten para ver queacute es lo que genera el problema

y maacutes tarde hacer un diagnostico ya que tenemos un diagnoacutestico 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 solucioacuten

y finalmente se va a hacer una evaluacioacuten para ver si se resolvioacute el problema

de raiacutez En caso de que si se funcione esta solucioacuten se pasa a la

documentacioacuten

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

por medio de una identificacioacuten 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 clasificacioacuten y se recurre a una evaluacioacuten de que tanto dantildeo genero

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

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

no se solucione posteriormente se hace la resolucioacuten o correccioacuten del error

7 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 13

(este puede deberse a varios aspectos configuraciones falta de seguridad

inconsistencia de datos etc) y este modelo tiene una fase muy difiacutecil que es

determinar que problemas estaacuten 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 pasariacutea si

cambio algunos de los datos en la configuracioacuten del sistema se tendriacutea que

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

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

Figura 4 Proceso de manejo de problemas

173 PROCESO DE MANEJO DE CONFIGURACIONES

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

configurado e instalado en cada sistema del cliente

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

mueve bajo cuatro veacutertices que son administracioacuten de cambios administracioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 14

de liberaciones administracioacuten de configuraciones y la administracioacuten de

procesos diversos8

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

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

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

manipular Aunque es lo maacutes parecido a la realidad porque nuestro entorno es

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

respecta a la administracioacuten de cambios vemos que se relaciona directamente

con la administracioacuten de incidentes y de problemas lo que conlleva una

planeacioacuten identificacioacuten control seguimiento del status verificacioacuten y

auditoria de configuraciones lo que hace que haya muchas variables

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

la liberacioacuten y distribucioacuten de nuevas versiones esto de da por una fase de

planeacioacuten identificacioacuten control revisioacuten del status verificacioacuten y auditoria y

puede depender de la administracioacuten de las capacidades ya que si no se

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

asiacute se hariacutea con todos los niveles hasta llegar al cierre del control de cambios

8 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 15

Figura 5 Proceso de manejo de configuraciones

174 PROCESO DE CONTROL DE CAMBIOS

El objetivo de este proceso es reducir los riesgos tanto teacutecnicos econoacutemicos y

de tiempo al momento de la realizacioacuten de los cambios

La Figura 6 al parecer es muy faacutecil 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 objetivos9

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

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

9 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 16

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

sea malo se pasa a la fase de reingenieriacutea 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 estaacute

probado se da la autorizacioacuten e implementacioacuten ya implementado se ve que no

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

tambieacuten se le considera como revisioacuten post-implementacioacuten

Figura 6 Proceso de control de cambios

175 PROCESO DE MANEJO DE ENTREGAS

Su objetivo es planear y controlar exitosamente la instalacioacuten 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 transicioacuten que se da de acuerdo

a los ambientes por los que se va dando la evolucioacuten del proyecto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 17

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

que hacer la liberacioacuten de las poliacuteticas la liberacioacuten de la planeacioacuten el disentildeo

loacutegico de la infraestructura que se va a implementar y la adquisicioacuten de

software y hardware estaacuten 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 construccioacuten y

liberacioacuten de las configuraciones (nivel loacutegico) se hacen las pruebas para

establecer los acuerdos de aceptacioacuten se da la aceptacioacuten total de versiones y

de modelos se arranca la planeacioacuten y finalmente las pruebas y

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

distribucioacuten e instalacioacuten 10

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

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

instalacioacuten

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

del servicio y no sabe que detraacutes del servicio que estaacute 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 maacutes 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 planeacioacuten monitoreo anaacutelisis y por un sin fin de pruebas con la intencioacuten

de que en caso de que algo no funcione se deacute en la fase de pruebas

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

afectado es el cliente

10

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 18

Figura 7 Proceso de manejo de entregas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 19

CAPITULO II

GESTION DE VERSIONES

21 Introduccioacuten y Objetivos

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

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

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

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

configuracioacuten de la infraestructura TI

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

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

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten 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 implementacioacuten de cualquier

cambio

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

proceso pero es tarea especiacutefica de la Gestioacuten de Versiones el disentildear poner a

prueba e instalar en el entorno de produccioacuten los cambios preestablecidos

Todo ello requiere de una cuidadosa planificacioacuten y coordinacioacuten con el resto

de procesos asociados a la Gestioacuten de Servicios TI

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 20

Entre los principales objetivos de la Gestioacuten de Versiones se incluyen

Establecer una poliacutetica de implementacioacuten de nuevas versiones de

hardware y software

Implementar las nuevas versiones de software y hardware en el entorno

de produccioacuten tras su verificacioacuten en un entorno realista de pruebas

Garantizar que el proceso de cambio cumpla las especificaciones de la

RFC correspondiente

Asegurar en colaboracioacuten con la Gestioacuten de Cambios y

Configuraciones que todos los cambios se ven correctamente reflejados

en la CMDB

Archivar copias ideacutenticas del software en produccioacuten asiacute como de toda

su documentacioacuten asociada en la Biblioteca de Software Definitivo

(DSL)

Mantener actualizado el Depoacutesito de Hardware Definitivo (DHS)

22 Beneficios y Dificultades

Los beneficios de una correcta Gestioacuten 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 nuacutemero de incidentes por incompatibilidades con otro

software o hardware instalado

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

software y hardware a instalar sino que tambieacuten permite conocer la

opinioacuten 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 nuacutemero de copias de software ilegales

Control centralizado del software y hardware desplegado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 21

Proteccioacuten contra virus y problemas asociados a versiones de software

incontroladas

Las principales dificultades con las que topa la Gestioacuten de Versiones son

No existe una clara asignacioacuten de responsabilidades yo la organizacioacuten

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

proceso de implementacioacuten 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 centralizacioacuten del

proceso de cambio Es habitual que existan reticencias a adoptar

sistemas estandarizados en toda la organizacioacuten sobre todo cuando

eacutesta no ha sido la poliacutetica tradicional de la misma

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

argumentado que estos soacutelo son responsabilidad de un determinado

grupo de trabajo o que su urgencia requeriacutea de ello

Hay resistencias a aceptar posibles planes de back-out Ciertos

entornos de produccioacuten pueden elegir ignorar lo problemas que una

nueva versioacuten puede provocar en otras aacutereas y resistirse a volver a la

uacuteltima versioacuten estable

La implementacioacuten sincronizada de versiones en entornos altamente

distribuidos

La solucioacuten a estos problemas pasa por

Un firme compromiso de la organizacioacuten con la Gestioacuten de Versiones y

sus responsables

Un adecuado plan de comunicacioacuten que informe a todos los

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

correcta gestioacuten de todo el proceso de cambio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 22

Una versioacuten es un grupo de CIs de nueva creacioacuten o modificados que han sido

validados para su instalacioacuten en el entorno de produccioacuten Las especificaciones

funcionales y teacutecnicas de una versioacuten estaacuten determinadas en la RFC

correspondiente

23 Clasificacioacuten de las Versiones

Las versiones pueden clasificarse seguacuten 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 caracteriacutesticas teacutecnicas etc

Versiones menores que suelen implicar la correccioacuten 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 raacutepida

un error conocido

Como pueden llegar a existir muacuteltiples versiones es conveniente definir una

referencia o coacutedigo que los identifique uniacutevocamente El sistema

universalmente aceptado es

Versiones mayores 10 20 etc

Versiones menores 11 12 13 etc

Versiones de emergencia 111 112 etc

Aunque en algunos casos esta clasificacioacuten se refina auacuten maacutes (vea por

ejemplo en la ayuda la versioacuten de su navegador)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 23

En su ciclo de vida una versioacuten puede encontrase en diversos estados

desarrollo pruebas produccioacuten y archivado11

En la Figura 8 nos ilustra graacuteficamente la evolucioacuten temporal de una versioacuten

Figura 8 Evolucioacuten temporal de una versioacuten

El despliegue de nuevas versiones puede realizarse de diferentes maneras y

es responsabilidad de la Gestioacuten de Cambios el determinar la forma maacutes

conveniente de hacerlo Entre las opciones maacutes habituales cabe contar

Versioacuten delta soacutelo se testean e instalan los elementos modificados

Esta opcioacuten tiene como ventaja su mayor simplicidad pero conlleva el

peligro de que puedan aparecer problemas e incompatibilidades en el

entorno de produccioacuten

Versioacuten completa Se distribuyen todos los elementos afectados ya

hayan sido modificados o no Aunque esta opcioacuten es obviamente maacutes

trabajosa es maacutes improbable que se generen incidentes tras la

instalacioacuten si se han realizado las pruebas pertinentes

11

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 24

Paquete de Versiones La Gestioacuten 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 opcioacuten es obligada por incompatibilidades entre una nueva

versioacuten con software o hardware previamente instalado Pensemos por

ejemplo en la migracioacuten a un nuevo sistema operativo que requiere

hardware maacutes avanzado yo nuevos versiones de los programas

ofimaacuteticos

24 Visioacuten General

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

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

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

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

configuracioacuten de la infraestructura TI12

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

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

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten de Versiones se resumen

sucintamente en la siguiente Figura 9

12

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 25

Figura 9 Visioacuten General de la Gestioacuten de Versiones

25 Planificacioacuten

Es crucial establecer un marco general para el lanzamiento de nuevas

versiones que fije una metodologiacutea 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

especiacuteficos que tomen en cuenta las peculiaridades de cada caso

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

deben de tomar en cuenta los siguientes factores

Coacutemo puede afectar la nueva versioacuten a otras aacutereas del entramado TI

Queacute CIs se veraacuten directa o indirectamente implicados durante y tras el

lanzamiento de la nueva versioacuten

Coacutemo ha de construirse el entorno de pruebas para que eacuteste sea fiel

reflejo del entorno de produccioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 26

Queacute planes de back-out son necesarios

Coacutemo y cuaacutendo se deben implementar los planes de back-out para

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

sistema TI

Cuaacuteles son los recursos humanos y teacutecnicos necesarios para llevar a

cabo la implementacioacuten de la nueva versioacuten con garantiacuteas de eacutexito

Quieacutenes seraacuten los responsables directos en las diferentes etapas del

proceso

Queacute planes de comunicacioacuten yo formacioacuten deben desarrollarse para

que los usuarios esteacuten puntualmente informados y puedan percibir la

nueva versioacuten como una mejora

Queacute tipo de despliegue es el maacutes adecuado completo delta

sincronizado en todas los emplazamientos gradual

Cuaacutel es la vida media uacutetil esperada de la nueva versioacuten

Queacute impacto puede tener el proceso de lanzamiento de la nueva versioacuten

en la calidad del servicio

Si es posible establecer meacutetricas precisas que determinen el grado de

eacutexito del lanzamiento de la nueva versioacuten

26 Desarrollo

La Gestioacuten de Versiones es la encargada del disentildeo y construccioacuten de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes

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

participacioacuten de proveedores externos En este segundo caso la tarea de la

Gestioacuten de Versiones seraacute la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC Asimismo la Gestioacuten de Versiones seraacute la responsable de todo el

proceso de configuracioacuten necesario

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

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

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

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

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

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

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

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

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

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

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

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

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

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

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

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

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

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

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

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

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

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

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

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

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

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

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

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

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

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

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

de impedir que otro usuario pueda modificar dicho elemento

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

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

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

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

los planes de back-out14

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

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

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

CIs (Configuration Items) en el entorno de produccioacuten

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

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

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

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

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

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

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

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

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

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

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

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

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

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

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

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

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

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

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

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

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

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

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

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

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

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

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

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

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

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

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

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

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

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

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

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

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

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

cliente servidor

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

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

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

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

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

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

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

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

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

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

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

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

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

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

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

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

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

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

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

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

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

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

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

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

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

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

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

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

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

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

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

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

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

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

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

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

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

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

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

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

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

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

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

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

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

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

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

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

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

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

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

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

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

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

podemos hacer un branching retroactivo pero hacer un branching retroactivo

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

trabajar en otra rama

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

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

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

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

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

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

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

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

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

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

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

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

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

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

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

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

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

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

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

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

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

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

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

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 4: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 4

bull A traveacutes de las mejores praacutecticas de ITIL se apoya al cambio en la cultura de

TI y su orientacioacuten hacia el servicio y se facilita la introduccioacuten de un sistema

de administracioacuten de calidad

bull ITIL proporciona un marco de referencia uniforme para la comunicacioacuten

interna y con proveedores

Desventajas

bull Tiempo y esfuerzo necesario para su implementacioacuten

bull Que no se deacute el cambio en la cultura de las aacutereas involucradas

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

procesos indicadores y como pueden ser controlados

bull Que el personal no se involucre y se comprometa

bull La mejora del servicio y la reduccioacuten de costos puede no ser visible

bull Que la inversioacuten en herramientas de soporte sea escasa Los procesos

podraacuten parecer inuacutetiles y no se alcancen las mejoras en los servicios

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

Tecnologiacutea ITIL

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 5

Figura 1 ITIL en Managed Services

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

Seguacuten la Figura 2 vemos como aparentemente tenemos segmentos del

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

de las soluciones Por ejemplo la prestacioacuten de servicios muchas veces no

seriacutea posible sin la gestioacuten de infraestructura asimismo las perspectivas del

negocio no se dariacutean sin la prestacioacuten de servicio y los servicios no serian

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

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

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

prestacioacuten de servicios la prestacioacuten de servicios requiere que se le de un

soporte al servicio para que este siempre disponible la disponibilidad la

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

al centro las soluciones vamos a tener a los clientes satisfechos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 6

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

interaccioacuten que se da entre las diferentes aacutereas de un negocio es la buacutesqueda

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

esteacuten soportadas entre siacute por medio del sistema1

Figura2 Soluciones para ITIL desde el punto de vista de negocio

14 Certificacioacuten

Los particulares pueden conseguir varias certificaciones oficiales ITIL Los

estaacutendares de calificacioacuten 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 Paiacuteses Bajos) e

ISEB (con sede en el Reino Unido)

Existen tres niveles de certificacioacuten ITIL para profesionales

1 Foundation Certificate (Certificado Baacutesico) acredita un conocimiento

baacutesico de ITIL en gestioacuten de servicios de tecnologiacuteas de la informacioacuten y

1 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtml

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 7

la comprensioacuten de la terminologiacutea propia de ITIL Estaacute destinado a

aquellas personas que deseen conocer las buenas praacutecticas

especificadas en ITIL

2 Practitioners Certificate (Certificado de Responsable) destinado a

quienes tienen responsabilidad en el disentildeo de procesos de

administracioacuten de departamentos de tecnologiacuteas de la informacioacuten y en

la planificacioacuten de las actividades asociadas a los procesos

3 Managers Certificate (Certificado de Director) garantiza que quien lo

posee dispone de profundos conocimientos en todas las materias

relacionadas con la administracioacuten de departamentos de tecnologiacuteas de

la informacioacuten y lo habilita para dirigir la implantacioacuten de soluciones

basadas en ITIL

No es posible certificar una organizacioacuten o sistema de gestioacuten como laquoconforme

a ITILraquo pero una organizacioacuten que haya implementado las guiacuteas de ITIL sobre

Gestioacuten de los Servicios de TI puede lograr certificarse bajo la ISOIEC 200002

La versioacuten 3 de ITIL que aparecioacute en junio de 2007 cambioacute 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)

15 Historia y precursores de ITIL

Lo que actualmente se conoce como ITIL versioacuten 1 desarrollada bajo el

auspicio de la CCTA se tituloacute Government Information Technology

Infrastructure Method (lsquoMeacutetodo de Infraestructura de la Tecnologiacutea de 2 httpeswikipediaorgwikiInformation_Technology_Infrastructure_Library

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 8

Informacioacuten del Gobiernorsquo GITM) y durante varios antildeos terminoacute expandieacutendose

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 guiacutea y no como un meacutetodo formal y como resultado del creciente

intereacutes que habiacutea fuera del gobierno britaacutenico

Muchos de los conceptos principales de gestioacuten 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 lsquoUn

sistema de gestioacuten para el negocio de la informacioacutenrsquo)[4] [5] fueron precursores

claves Seguacuten IBM

A principios de los antildeos 1980 IBM documentoacute los conceptos originales de

Gestioacuten de Sistemas en una serie de cuatro voluacutemenes 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 tomoacute prestado de ellos hasta

tales extremos

16 Criacuteticas a ITIL

ITIL ha recibido criacuteticas de varios frentes Entre ellas

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

marco holiacutestico y completo para el gobierno de TI

Su tendencia a convertirla en una religioacuten

Como sentildeala Jan van Bon (autor y editor de muchas publicaciones de Gestioacuten

de Servicios de TI)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 9

Hay mucha confusioacuten sobre ITIL procedente de todo tipo de malentendidos

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

praacutecticas La OGC no afirma que dichas mejoras praacutecticas describan procesos

puros ni tampoco que ITIL sea un marco disentildeado como un modelo coherente

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

tienen una gran necesidad de dicho modelo 3

El columnista CIO Magazine Dean Meyer tambieacuten ha expuesto algunos puntos

de vista cautelosos sobre ITIL incluyendo cinco trampas tiacutepicas tales como

laquoconvertirse en esclavo de definiciones desactualizadasraquo y laquodejar que ITIL se

convierta en religioacutenraquo Como Meyer sentildeala ITIL laquono describe el abanico

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

servicios actualesraquo4

La calidad de los voluacutemenes de la biblioteca se considera desigual Por

ejemplo Van Herwaarden y Grift sentildealan que laquola consistencia que

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

en los libros de entrega de servicioraquo5

17 Forma de uso de ITIL en Managed Services

ITIL postula que el servicio de soporte la administracioacuten y la operacioacuten se

realiza a traveacutes 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 Gestioacuten de Servicios de TI)

4 CIO Magazine Dean Meyer

5 Van Herwaarden y Grift

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 10

171 PROCESO DE MANEJO DE INCIDENTES

Su objetivo primordial es restablecer el servicio lo maacutes raacutepido posible para

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

minimicen los efectos de la operacioacuten Se dice que el proveedor de debe de

encargar de que el cliente no debe percibir todas aquellas pequentildeas 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 baacutesicos que son propiedad monitoreo manejo de secuencias y

comunicacioacuten

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

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

anomaliacutea 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 clasificacioacuten 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 seguacuten el manual de procedimientos para poder llegar a la

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

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

documentacioacuten y contabilizacioacuten del incidente para ver queacute tanta incidencia

tiene este caso finalmente se hace una evaluacioacuten para ver si efectivamente

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

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

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

se recurre a hacer una investigacioacuten y un diagnostico de la situacioacuten para ver

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

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 11

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

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

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

peo cuando el nivel de dantildeo es muy fuerte se da el caso de que se deacute por

perdido) y finamente se cierra el incidente y esta solucioacuten se documenta en

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

Data Base (aquiacute 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 maacutes faacutecil raacutepida y eficiente su resolucioacuten6

Figura 3 Proceso de manejo de incidentes

172 PROCESO DE MANEJO DE PROBLEMAS

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

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

6 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtml

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 12

ayuda a proporcionar soluciones raacutepidas 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 daacutendole 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 estaacute relacionada con lo que es el control del problema y la segunda

es con el control del error7

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

identificar el problema en base a alguna sintomatologiacutea ya que tenemos este

antecedente pasamos a la clasificacioacuten 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

estaacuten en el manual de procedimientos y en caso de no ser conocido se tendriacutea

que hacer una fase de investigacioacuten para ver queacute es lo que genera el problema

y maacutes tarde hacer un diagnostico ya que tenemos un diagnoacutestico 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 solucioacuten

y finalmente se va a hacer una evaluacioacuten para ver si se resolvioacute el problema

de raiacutez En caso de que si se funcione esta solucioacuten se pasa a la

documentacioacuten

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

por medio de una identificacioacuten 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 clasificacioacuten y se recurre a una evaluacioacuten de que tanto dantildeo genero

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

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

no se solucione posteriormente se hace la resolucioacuten o correccioacuten del error

7 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 13

(este puede deberse a varios aspectos configuraciones falta de seguridad

inconsistencia de datos etc) y este modelo tiene una fase muy difiacutecil que es

determinar que problemas estaacuten 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 pasariacutea si

cambio algunos de los datos en la configuracioacuten del sistema se tendriacutea que

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

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

Figura 4 Proceso de manejo de problemas

173 PROCESO DE MANEJO DE CONFIGURACIONES

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

configurado e instalado en cada sistema del cliente

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

mueve bajo cuatro veacutertices que son administracioacuten de cambios administracioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 14

de liberaciones administracioacuten de configuraciones y la administracioacuten de

procesos diversos8

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

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

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

manipular Aunque es lo maacutes parecido a la realidad porque nuestro entorno es

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

respecta a la administracioacuten de cambios vemos que se relaciona directamente

con la administracioacuten de incidentes y de problemas lo que conlleva una

planeacioacuten identificacioacuten control seguimiento del status verificacioacuten y

auditoria de configuraciones lo que hace que haya muchas variables

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

la liberacioacuten y distribucioacuten de nuevas versiones esto de da por una fase de

planeacioacuten identificacioacuten control revisioacuten del status verificacioacuten y auditoria y

puede depender de la administracioacuten de las capacidades ya que si no se

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

asiacute se hariacutea con todos los niveles hasta llegar al cierre del control de cambios

8 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 15

Figura 5 Proceso de manejo de configuraciones

174 PROCESO DE CONTROL DE CAMBIOS

El objetivo de este proceso es reducir los riesgos tanto teacutecnicos econoacutemicos y

de tiempo al momento de la realizacioacuten de los cambios

La Figura 6 al parecer es muy faacutecil 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 objetivos9

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

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

9 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 16

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

sea malo se pasa a la fase de reingenieriacutea 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 estaacute

probado se da la autorizacioacuten e implementacioacuten ya implementado se ve que no

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

tambieacuten se le considera como revisioacuten post-implementacioacuten

Figura 6 Proceso de control de cambios

175 PROCESO DE MANEJO DE ENTREGAS

Su objetivo es planear y controlar exitosamente la instalacioacuten 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 transicioacuten que se da de acuerdo

a los ambientes por los que se va dando la evolucioacuten del proyecto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 17

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

que hacer la liberacioacuten de las poliacuteticas la liberacioacuten de la planeacioacuten el disentildeo

loacutegico de la infraestructura que se va a implementar y la adquisicioacuten de

software y hardware estaacuten 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 construccioacuten y

liberacioacuten de las configuraciones (nivel loacutegico) se hacen las pruebas para

establecer los acuerdos de aceptacioacuten se da la aceptacioacuten total de versiones y

de modelos se arranca la planeacioacuten y finalmente las pruebas y

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

distribucioacuten e instalacioacuten 10

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

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

instalacioacuten

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

del servicio y no sabe que detraacutes del servicio que estaacute 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 maacutes 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 planeacioacuten monitoreo anaacutelisis y por un sin fin de pruebas con la intencioacuten

de que en caso de que algo no funcione se deacute en la fase de pruebas

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

afectado es el cliente

10

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 18

Figura 7 Proceso de manejo de entregas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 19

CAPITULO II

GESTION DE VERSIONES

21 Introduccioacuten y Objetivos

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

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

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

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

configuracioacuten de la infraestructura TI

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

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

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten 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 implementacioacuten de cualquier

cambio

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

proceso pero es tarea especiacutefica de la Gestioacuten de Versiones el disentildear poner a

prueba e instalar en el entorno de produccioacuten los cambios preestablecidos

Todo ello requiere de una cuidadosa planificacioacuten y coordinacioacuten con el resto

de procesos asociados a la Gestioacuten de Servicios TI

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 20

Entre los principales objetivos de la Gestioacuten de Versiones se incluyen

Establecer una poliacutetica de implementacioacuten de nuevas versiones de

hardware y software

Implementar las nuevas versiones de software y hardware en el entorno

de produccioacuten tras su verificacioacuten en un entorno realista de pruebas

Garantizar que el proceso de cambio cumpla las especificaciones de la

RFC correspondiente

Asegurar en colaboracioacuten con la Gestioacuten de Cambios y

Configuraciones que todos los cambios se ven correctamente reflejados

en la CMDB

Archivar copias ideacutenticas del software en produccioacuten asiacute como de toda

su documentacioacuten asociada en la Biblioteca de Software Definitivo

(DSL)

Mantener actualizado el Depoacutesito de Hardware Definitivo (DHS)

22 Beneficios y Dificultades

Los beneficios de una correcta Gestioacuten 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 nuacutemero de incidentes por incompatibilidades con otro

software o hardware instalado

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

software y hardware a instalar sino que tambieacuten permite conocer la

opinioacuten 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 nuacutemero de copias de software ilegales

Control centralizado del software y hardware desplegado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 21

Proteccioacuten contra virus y problemas asociados a versiones de software

incontroladas

Las principales dificultades con las que topa la Gestioacuten de Versiones son

No existe una clara asignacioacuten de responsabilidades yo la organizacioacuten

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

proceso de implementacioacuten 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 centralizacioacuten del

proceso de cambio Es habitual que existan reticencias a adoptar

sistemas estandarizados en toda la organizacioacuten sobre todo cuando

eacutesta no ha sido la poliacutetica tradicional de la misma

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

argumentado que estos soacutelo son responsabilidad de un determinado

grupo de trabajo o que su urgencia requeriacutea de ello

Hay resistencias a aceptar posibles planes de back-out Ciertos

entornos de produccioacuten pueden elegir ignorar lo problemas que una

nueva versioacuten puede provocar en otras aacutereas y resistirse a volver a la

uacuteltima versioacuten estable

La implementacioacuten sincronizada de versiones en entornos altamente

distribuidos

La solucioacuten a estos problemas pasa por

Un firme compromiso de la organizacioacuten con la Gestioacuten de Versiones y

sus responsables

Un adecuado plan de comunicacioacuten que informe a todos los

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

correcta gestioacuten de todo el proceso de cambio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 22

Una versioacuten es un grupo de CIs de nueva creacioacuten o modificados que han sido

validados para su instalacioacuten en el entorno de produccioacuten Las especificaciones

funcionales y teacutecnicas de una versioacuten estaacuten determinadas en la RFC

correspondiente

23 Clasificacioacuten de las Versiones

Las versiones pueden clasificarse seguacuten 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 caracteriacutesticas teacutecnicas etc

Versiones menores que suelen implicar la correccioacuten 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 raacutepida

un error conocido

Como pueden llegar a existir muacuteltiples versiones es conveniente definir una

referencia o coacutedigo que los identifique uniacutevocamente El sistema

universalmente aceptado es

Versiones mayores 10 20 etc

Versiones menores 11 12 13 etc

Versiones de emergencia 111 112 etc

Aunque en algunos casos esta clasificacioacuten se refina auacuten maacutes (vea por

ejemplo en la ayuda la versioacuten de su navegador)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 23

En su ciclo de vida una versioacuten puede encontrase en diversos estados

desarrollo pruebas produccioacuten y archivado11

En la Figura 8 nos ilustra graacuteficamente la evolucioacuten temporal de una versioacuten

Figura 8 Evolucioacuten temporal de una versioacuten

El despliegue de nuevas versiones puede realizarse de diferentes maneras y

es responsabilidad de la Gestioacuten de Cambios el determinar la forma maacutes

conveniente de hacerlo Entre las opciones maacutes habituales cabe contar

Versioacuten delta soacutelo se testean e instalan los elementos modificados

Esta opcioacuten tiene como ventaja su mayor simplicidad pero conlleva el

peligro de que puedan aparecer problemas e incompatibilidades en el

entorno de produccioacuten

Versioacuten completa Se distribuyen todos los elementos afectados ya

hayan sido modificados o no Aunque esta opcioacuten es obviamente maacutes

trabajosa es maacutes improbable que se generen incidentes tras la

instalacioacuten si se han realizado las pruebas pertinentes

11

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 24

Paquete de Versiones La Gestioacuten 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 opcioacuten es obligada por incompatibilidades entre una nueva

versioacuten con software o hardware previamente instalado Pensemos por

ejemplo en la migracioacuten a un nuevo sistema operativo que requiere

hardware maacutes avanzado yo nuevos versiones de los programas

ofimaacuteticos

24 Visioacuten General

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

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

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

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

configuracioacuten de la infraestructura TI12

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

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

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten de Versiones se resumen

sucintamente en la siguiente Figura 9

12

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 25

Figura 9 Visioacuten General de la Gestioacuten de Versiones

25 Planificacioacuten

Es crucial establecer un marco general para el lanzamiento de nuevas

versiones que fije una metodologiacutea 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

especiacuteficos que tomen en cuenta las peculiaridades de cada caso

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

deben de tomar en cuenta los siguientes factores

Coacutemo puede afectar la nueva versioacuten a otras aacutereas del entramado TI

Queacute CIs se veraacuten directa o indirectamente implicados durante y tras el

lanzamiento de la nueva versioacuten

Coacutemo ha de construirse el entorno de pruebas para que eacuteste sea fiel

reflejo del entorno de produccioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 26

Queacute planes de back-out son necesarios

Coacutemo y cuaacutendo se deben implementar los planes de back-out para

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

sistema TI

Cuaacuteles son los recursos humanos y teacutecnicos necesarios para llevar a

cabo la implementacioacuten de la nueva versioacuten con garantiacuteas de eacutexito

Quieacutenes seraacuten los responsables directos en las diferentes etapas del

proceso

Queacute planes de comunicacioacuten yo formacioacuten deben desarrollarse para

que los usuarios esteacuten puntualmente informados y puedan percibir la

nueva versioacuten como una mejora

Queacute tipo de despliegue es el maacutes adecuado completo delta

sincronizado en todas los emplazamientos gradual

Cuaacutel es la vida media uacutetil esperada de la nueva versioacuten

Queacute impacto puede tener el proceso de lanzamiento de la nueva versioacuten

en la calidad del servicio

Si es posible establecer meacutetricas precisas que determinen el grado de

eacutexito del lanzamiento de la nueva versioacuten

26 Desarrollo

La Gestioacuten de Versiones es la encargada del disentildeo y construccioacuten de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes

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

participacioacuten de proveedores externos En este segundo caso la tarea de la

Gestioacuten de Versiones seraacute la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC Asimismo la Gestioacuten de Versiones seraacute la responsable de todo el

proceso de configuracioacuten necesario

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

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

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

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

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

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

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

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

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

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

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

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

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

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

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

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

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

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

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

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

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

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

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

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

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

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

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

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

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

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

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

de impedir que otro usuario pueda modificar dicho elemento

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

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

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

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

los planes de back-out14

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

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

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

CIs (Configuration Items) en el entorno de produccioacuten

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

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

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

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

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

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

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

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

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

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

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

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

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

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

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

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

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

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

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

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

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

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

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

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

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

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

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

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

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

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

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

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

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

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

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

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

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

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

cliente servidor

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

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

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

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

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

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

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

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

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

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

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

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

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

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

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

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

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

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

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

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

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

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

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

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

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

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

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

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

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

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

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

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

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

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

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

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

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

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

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

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

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

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

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

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

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

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

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

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

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

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

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

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

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

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

podemos hacer un branching retroactivo pero hacer un branching retroactivo

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

trabajar en otra rama

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

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

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

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

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

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

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

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

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

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

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

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

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

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

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

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

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

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

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

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

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

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

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

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 5: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 5

Figura 1 ITIL en Managed Services

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

Seguacuten la Figura 2 vemos como aparentemente tenemos segmentos del

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

de las soluciones Por ejemplo la prestacioacuten de servicios muchas veces no

seriacutea posible sin la gestioacuten de infraestructura asimismo las perspectivas del

negocio no se dariacutean sin la prestacioacuten de servicio y los servicios no serian

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

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

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

prestacioacuten de servicios la prestacioacuten de servicios requiere que se le de un

soporte al servicio para que este siempre disponible la disponibilidad la

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

al centro las soluciones vamos a tener a los clientes satisfechos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 6

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

interaccioacuten que se da entre las diferentes aacutereas de un negocio es la buacutesqueda

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

esteacuten soportadas entre siacute por medio del sistema1

Figura2 Soluciones para ITIL desde el punto de vista de negocio

14 Certificacioacuten

Los particulares pueden conseguir varias certificaciones oficiales ITIL Los

estaacutendares de calificacioacuten 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 Paiacuteses Bajos) e

ISEB (con sede en el Reino Unido)

Existen tres niveles de certificacioacuten ITIL para profesionales

1 Foundation Certificate (Certificado Baacutesico) acredita un conocimiento

baacutesico de ITIL en gestioacuten de servicios de tecnologiacuteas de la informacioacuten y

1 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtml

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 7

la comprensioacuten de la terminologiacutea propia de ITIL Estaacute destinado a

aquellas personas que deseen conocer las buenas praacutecticas

especificadas en ITIL

2 Practitioners Certificate (Certificado de Responsable) destinado a

quienes tienen responsabilidad en el disentildeo de procesos de

administracioacuten de departamentos de tecnologiacuteas de la informacioacuten y en

la planificacioacuten de las actividades asociadas a los procesos

3 Managers Certificate (Certificado de Director) garantiza que quien lo

posee dispone de profundos conocimientos en todas las materias

relacionadas con la administracioacuten de departamentos de tecnologiacuteas de

la informacioacuten y lo habilita para dirigir la implantacioacuten de soluciones

basadas en ITIL

No es posible certificar una organizacioacuten o sistema de gestioacuten como laquoconforme

a ITILraquo pero una organizacioacuten que haya implementado las guiacuteas de ITIL sobre

Gestioacuten de los Servicios de TI puede lograr certificarse bajo la ISOIEC 200002

La versioacuten 3 de ITIL que aparecioacute en junio de 2007 cambioacute 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)

15 Historia y precursores de ITIL

Lo que actualmente se conoce como ITIL versioacuten 1 desarrollada bajo el

auspicio de la CCTA se tituloacute Government Information Technology

Infrastructure Method (lsquoMeacutetodo de Infraestructura de la Tecnologiacutea de 2 httpeswikipediaorgwikiInformation_Technology_Infrastructure_Library

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 8

Informacioacuten del Gobiernorsquo GITM) y durante varios antildeos terminoacute expandieacutendose

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 guiacutea y no como un meacutetodo formal y como resultado del creciente

intereacutes que habiacutea fuera del gobierno britaacutenico

Muchos de los conceptos principales de gestioacuten 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 lsquoUn

sistema de gestioacuten para el negocio de la informacioacutenrsquo)[4] [5] fueron precursores

claves Seguacuten IBM

A principios de los antildeos 1980 IBM documentoacute los conceptos originales de

Gestioacuten de Sistemas en una serie de cuatro voluacutemenes 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 tomoacute prestado de ellos hasta

tales extremos

16 Criacuteticas a ITIL

ITIL ha recibido criacuteticas de varios frentes Entre ellas

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

marco holiacutestico y completo para el gobierno de TI

Su tendencia a convertirla en una religioacuten

Como sentildeala Jan van Bon (autor y editor de muchas publicaciones de Gestioacuten

de Servicios de TI)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 9

Hay mucha confusioacuten sobre ITIL procedente de todo tipo de malentendidos

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

praacutecticas La OGC no afirma que dichas mejoras praacutecticas describan procesos

puros ni tampoco que ITIL sea un marco disentildeado como un modelo coherente

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

tienen una gran necesidad de dicho modelo 3

El columnista CIO Magazine Dean Meyer tambieacuten ha expuesto algunos puntos

de vista cautelosos sobre ITIL incluyendo cinco trampas tiacutepicas tales como

laquoconvertirse en esclavo de definiciones desactualizadasraquo y laquodejar que ITIL se

convierta en religioacutenraquo Como Meyer sentildeala ITIL laquono describe el abanico

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

servicios actualesraquo4

La calidad de los voluacutemenes de la biblioteca se considera desigual Por

ejemplo Van Herwaarden y Grift sentildealan que laquola consistencia que

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

en los libros de entrega de servicioraquo5

17 Forma de uso de ITIL en Managed Services

ITIL postula que el servicio de soporte la administracioacuten y la operacioacuten se

realiza a traveacutes 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 Gestioacuten de Servicios de TI)

4 CIO Magazine Dean Meyer

5 Van Herwaarden y Grift

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 10

171 PROCESO DE MANEJO DE INCIDENTES

Su objetivo primordial es restablecer el servicio lo maacutes raacutepido posible para

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

minimicen los efectos de la operacioacuten Se dice que el proveedor de debe de

encargar de que el cliente no debe percibir todas aquellas pequentildeas 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 baacutesicos que son propiedad monitoreo manejo de secuencias y

comunicacioacuten

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

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

anomaliacutea 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 clasificacioacuten 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 seguacuten el manual de procedimientos para poder llegar a la

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

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

documentacioacuten y contabilizacioacuten del incidente para ver queacute tanta incidencia

tiene este caso finalmente se hace una evaluacioacuten para ver si efectivamente

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

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

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

se recurre a hacer una investigacioacuten y un diagnostico de la situacioacuten para ver

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

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 11

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

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

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

peo cuando el nivel de dantildeo es muy fuerte se da el caso de que se deacute por

perdido) y finamente se cierra el incidente y esta solucioacuten se documenta en

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

Data Base (aquiacute 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 maacutes faacutecil raacutepida y eficiente su resolucioacuten6

Figura 3 Proceso de manejo de incidentes

172 PROCESO DE MANEJO DE PROBLEMAS

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

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

6 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtml

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 12

ayuda a proporcionar soluciones raacutepidas 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 daacutendole 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 estaacute relacionada con lo que es el control del problema y la segunda

es con el control del error7

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

identificar el problema en base a alguna sintomatologiacutea ya que tenemos este

antecedente pasamos a la clasificacioacuten 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

estaacuten en el manual de procedimientos y en caso de no ser conocido se tendriacutea

que hacer una fase de investigacioacuten para ver queacute es lo que genera el problema

y maacutes tarde hacer un diagnostico ya que tenemos un diagnoacutestico 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 solucioacuten

y finalmente se va a hacer una evaluacioacuten para ver si se resolvioacute el problema

de raiacutez En caso de que si se funcione esta solucioacuten se pasa a la

documentacioacuten

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

por medio de una identificacioacuten 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 clasificacioacuten y se recurre a una evaluacioacuten de que tanto dantildeo genero

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

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

no se solucione posteriormente se hace la resolucioacuten o correccioacuten del error

7 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 13

(este puede deberse a varios aspectos configuraciones falta de seguridad

inconsistencia de datos etc) y este modelo tiene una fase muy difiacutecil que es

determinar que problemas estaacuten 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 pasariacutea si

cambio algunos de los datos en la configuracioacuten del sistema se tendriacutea que

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

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

Figura 4 Proceso de manejo de problemas

173 PROCESO DE MANEJO DE CONFIGURACIONES

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

configurado e instalado en cada sistema del cliente

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

mueve bajo cuatro veacutertices que son administracioacuten de cambios administracioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 14

de liberaciones administracioacuten de configuraciones y la administracioacuten de

procesos diversos8

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

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

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

manipular Aunque es lo maacutes parecido a la realidad porque nuestro entorno es

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

respecta a la administracioacuten de cambios vemos que se relaciona directamente

con la administracioacuten de incidentes y de problemas lo que conlleva una

planeacioacuten identificacioacuten control seguimiento del status verificacioacuten y

auditoria de configuraciones lo que hace que haya muchas variables

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

la liberacioacuten y distribucioacuten de nuevas versiones esto de da por una fase de

planeacioacuten identificacioacuten control revisioacuten del status verificacioacuten y auditoria y

puede depender de la administracioacuten de las capacidades ya que si no se

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

asiacute se hariacutea con todos los niveles hasta llegar al cierre del control de cambios

8 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 15

Figura 5 Proceso de manejo de configuraciones

174 PROCESO DE CONTROL DE CAMBIOS

El objetivo de este proceso es reducir los riesgos tanto teacutecnicos econoacutemicos y

de tiempo al momento de la realizacioacuten de los cambios

La Figura 6 al parecer es muy faacutecil 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 objetivos9

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

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

9 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 16

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

sea malo se pasa a la fase de reingenieriacutea 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 estaacute

probado se da la autorizacioacuten e implementacioacuten ya implementado se ve que no

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

tambieacuten se le considera como revisioacuten post-implementacioacuten

Figura 6 Proceso de control de cambios

175 PROCESO DE MANEJO DE ENTREGAS

Su objetivo es planear y controlar exitosamente la instalacioacuten 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 transicioacuten que se da de acuerdo

a los ambientes por los que se va dando la evolucioacuten del proyecto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 17

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

que hacer la liberacioacuten de las poliacuteticas la liberacioacuten de la planeacioacuten el disentildeo

loacutegico de la infraestructura que se va a implementar y la adquisicioacuten de

software y hardware estaacuten 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 construccioacuten y

liberacioacuten de las configuraciones (nivel loacutegico) se hacen las pruebas para

establecer los acuerdos de aceptacioacuten se da la aceptacioacuten total de versiones y

de modelos se arranca la planeacioacuten y finalmente las pruebas y

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

distribucioacuten e instalacioacuten 10

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

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

instalacioacuten

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

del servicio y no sabe que detraacutes del servicio que estaacute 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 maacutes 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 planeacioacuten monitoreo anaacutelisis y por un sin fin de pruebas con la intencioacuten

de que en caso de que algo no funcione se deacute en la fase de pruebas

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

afectado es el cliente

10

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 18

Figura 7 Proceso de manejo de entregas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 19

CAPITULO II

GESTION DE VERSIONES

21 Introduccioacuten y Objetivos

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

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

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

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

configuracioacuten de la infraestructura TI

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

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

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten 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 implementacioacuten de cualquier

cambio

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

proceso pero es tarea especiacutefica de la Gestioacuten de Versiones el disentildear poner a

prueba e instalar en el entorno de produccioacuten los cambios preestablecidos

Todo ello requiere de una cuidadosa planificacioacuten y coordinacioacuten con el resto

de procesos asociados a la Gestioacuten de Servicios TI

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 20

Entre los principales objetivos de la Gestioacuten de Versiones se incluyen

Establecer una poliacutetica de implementacioacuten de nuevas versiones de

hardware y software

Implementar las nuevas versiones de software y hardware en el entorno

de produccioacuten tras su verificacioacuten en un entorno realista de pruebas

Garantizar que el proceso de cambio cumpla las especificaciones de la

RFC correspondiente

Asegurar en colaboracioacuten con la Gestioacuten de Cambios y

Configuraciones que todos los cambios se ven correctamente reflejados

en la CMDB

Archivar copias ideacutenticas del software en produccioacuten asiacute como de toda

su documentacioacuten asociada en la Biblioteca de Software Definitivo

(DSL)

Mantener actualizado el Depoacutesito de Hardware Definitivo (DHS)

22 Beneficios y Dificultades

Los beneficios de una correcta Gestioacuten 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 nuacutemero de incidentes por incompatibilidades con otro

software o hardware instalado

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

software y hardware a instalar sino que tambieacuten permite conocer la

opinioacuten 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 nuacutemero de copias de software ilegales

Control centralizado del software y hardware desplegado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 21

Proteccioacuten contra virus y problemas asociados a versiones de software

incontroladas

Las principales dificultades con las que topa la Gestioacuten de Versiones son

No existe una clara asignacioacuten de responsabilidades yo la organizacioacuten

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

proceso de implementacioacuten 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 centralizacioacuten del

proceso de cambio Es habitual que existan reticencias a adoptar

sistemas estandarizados en toda la organizacioacuten sobre todo cuando

eacutesta no ha sido la poliacutetica tradicional de la misma

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

argumentado que estos soacutelo son responsabilidad de un determinado

grupo de trabajo o que su urgencia requeriacutea de ello

Hay resistencias a aceptar posibles planes de back-out Ciertos

entornos de produccioacuten pueden elegir ignorar lo problemas que una

nueva versioacuten puede provocar en otras aacutereas y resistirse a volver a la

uacuteltima versioacuten estable

La implementacioacuten sincronizada de versiones en entornos altamente

distribuidos

La solucioacuten a estos problemas pasa por

Un firme compromiso de la organizacioacuten con la Gestioacuten de Versiones y

sus responsables

Un adecuado plan de comunicacioacuten que informe a todos los

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

correcta gestioacuten de todo el proceso de cambio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 22

Una versioacuten es un grupo de CIs de nueva creacioacuten o modificados que han sido

validados para su instalacioacuten en el entorno de produccioacuten Las especificaciones

funcionales y teacutecnicas de una versioacuten estaacuten determinadas en la RFC

correspondiente

23 Clasificacioacuten de las Versiones

Las versiones pueden clasificarse seguacuten 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 caracteriacutesticas teacutecnicas etc

Versiones menores que suelen implicar la correccioacuten 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 raacutepida

un error conocido

Como pueden llegar a existir muacuteltiples versiones es conveniente definir una

referencia o coacutedigo que los identifique uniacutevocamente El sistema

universalmente aceptado es

Versiones mayores 10 20 etc

Versiones menores 11 12 13 etc

Versiones de emergencia 111 112 etc

Aunque en algunos casos esta clasificacioacuten se refina auacuten maacutes (vea por

ejemplo en la ayuda la versioacuten de su navegador)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 23

En su ciclo de vida una versioacuten puede encontrase en diversos estados

desarrollo pruebas produccioacuten y archivado11

En la Figura 8 nos ilustra graacuteficamente la evolucioacuten temporal de una versioacuten

Figura 8 Evolucioacuten temporal de una versioacuten

El despliegue de nuevas versiones puede realizarse de diferentes maneras y

es responsabilidad de la Gestioacuten de Cambios el determinar la forma maacutes

conveniente de hacerlo Entre las opciones maacutes habituales cabe contar

Versioacuten delta soacutelo se testean e instalan los elementos modificados

Esta opcioacuten tiene como ventaja su mayor simplicidad pero conlleva el

peligro de que puedan aparecer problemas e incompatibilidades en el

entorno de produccioacuten

Versioacuten completa Se distribuyen todos los elementos afectados ya

hayan sido modificados o no Aunque esta opcioacuten es obviamente maacutes

trabajosa es maacutes improbable que se generen incidentes tras la

instalacioacuten si se han realizado las pruebas pertinentes

11

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 24

Paquete de Versiones La Gestioacuten 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 opcioacuten es obligada por incompatibilidades entre una nueva

versioacuten con software o hardware previamente instalado Pensemos por

ejemplo en la migracioacuten a un nuevo sistema operativo que requiere

hardware maacutes avanzado yo nuevos versiones de los programas

ofimaacuteticos

24 Visioacuten General

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

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

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

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

configuracioacuten de la infraestructura TI12

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

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

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten de Versiones se resumen

sucintamente en la siguiente Figura 9

12

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 25

Figura 9 Visioacuten General de la Gestioacuten de Versiones

25 Planificacioacuten

Es crucial establecer un marco general para el lanzamiento de nuevas

versiones que fije una metodologiacutea 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

especiacuteficos que tomen en cuenta las peculiaridades de cada caso

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

deben de tomar en cuenta los siguientes factores

Coacutemo puede afectar la nueva versioacuten a otras aacutereas del entramado TI

Queacute CIs se veraacuten directa o indirectamente implicados durante y tras el

lanzamiento de la nueva versioacuten

Coacutemo ha de construirse el entorno de pruebas para que eacuteste sea fiel

reflejo del entorno de produccioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 26

Queacute planes de back-out son necesarios

Coacutemo y cuaacutendo se deben implementar los planes de back-out para

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

sistema TI

Cuaacuteles son los recursos humanos y teacutecnicos necesarios para llevar a

cabo la implementacioacuten de la nueva versioacuten con garantiacuteas de eacutexito

Quieacutenes seraacuten los responsables directos en las diferentes etapas del

proceso

Queacute planes de comunicacioacuten yo formacioacuten deben desarrollarse para

que los usuarios esteacuten puntualmente informados y puedan percibir la

nueva versioacuten como una mejora

Queacute tipo de despliegue es el maacutes adecuado completo delta

sincronizado en todas los emplazamientos gradual

Cuaacutel es la vida media uacutetil esperada de la nueva versioacuten

Queacute impacto puede tener el proceso de lanzamiento de la nueva versioacuten

en la calidad del servicio

Si es posible establecer meacutetricas precisas que determinen el grado de

eacutexito del lanzamiento de la nueva versioacuten

26 Desarrollo

La Gestioacuten de Versiones es la encargada del disentildeo y construccioacuten de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes

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

participacioacuten de proveedores externos En este segundo caso la tarea de la

Gestioacuten de Versiones seraacute la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC Asimismo la Gestioacuten de Versiones seraacute la responsable de todo el

proceso de configuracioacuten necesario

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

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

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

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

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

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

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

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

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

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

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

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

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

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

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

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

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

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

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

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

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

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

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

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

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

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

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

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

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

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

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

de impedir que otro usuario pueda modificar dicho elemento

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

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

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

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

los planes de back-out14

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

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

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

CIs (Configuration Items) en el entorno de produccioacuten

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

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

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

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

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

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

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

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

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

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

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

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

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

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

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

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

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

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

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

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

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

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

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

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

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

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

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

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

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

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

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

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

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

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

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

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

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

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

cliente servidor

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

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

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

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

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

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

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

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

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

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

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

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

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

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

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

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

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

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

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

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

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

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

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

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

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

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

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

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

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

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

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

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

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

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

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

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

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

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

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

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

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

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

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

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

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

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

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

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

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

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

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

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

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

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

podemos hacer un branching retroactivo pero hacer un branching retroactivo

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

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 6: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 6

Las aacutereas de un negocio no pueden estar aisladas unas de otras El punto de

interaccioacuten que se da entre las diferentes aacutereas de un negocio es la buacutesqueda

de soluciones donde lo que se pretende es que las perspectivas del negocio

esteacuten soportadas entre siacute por medio del sistema1

Figura2 Soluciones para ITIL desde el punto de vista de negocio

14 Certificacioacuten

Los particulares pueden conseguir varias certificaciones oficiales ITIL Los

estaacutendares de calificacioacuten 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 Paiacuteses Bajos) e

ISEB (con sede en el Reino Unido)

Existen tres niveles de certificacioacuten ITIL para profesionales

1 Foundation Certificate (Certificado Baacutesico) acredita un conocimiento

baacutesico de ITIL en gestioacuten de servicios de tecnologiacuteas de la informacioacuten y

1 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtml

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 7

la comprensioacuten de la terminologiacutea propia de ITIL Estaacute destinado a

aquellas personas que deseen conocer las buenas praacutecticas

especificadas en ITIL

2 Practitioners Certificate (Certificado de Responsable) destinado a

quienes tienen responsabilidad en el disentildeo de procesos de

administracioacuten de departamentos de tecnologiacuteas de la informacioacuten y en

la planificacioacuten de las actividades asociadas a los procesos

3 Managers Certificate (Certificado de Director) garantiza que quien lo

posee dispone de profundos conocimientos en todas las materias

relacionadas con la administracioacuten de departamentos de tecnologiacuteas de

la informacioacuten y lo habilita para dirigir la implantacioacuten de soluciones

basadas en ITIL

No es posible certificar una organizacioacuten o sistema de gestioacuten como laquoconforme

a ITILraquo pero una organizacioacuten que haya implementado las guiacuteas de ITIL sobre

Gestioacuten de los Servicios de TI puede lograr certificarse bajo la ISOIEC 200002

La versioacuten 3 de ITIL que aparecioacute en junio de 2007 cambioacute 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)

15 Historia y precursores de ITIL

Lo que actualmente se conoce como ITIL versioacuten 1 desarrollada bajo el

auspicio de la CCTA se tituloacute Government Information Technology

Infrastructure Method (lsquoMeacutetodo de Infraestructura de la Tecnologiacutea de 2 httpeswikipediaorgwikiInformation_Technology_Infrastructure_Library

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 8

Informacioacuten del Gobiernorsquo GITM) y durante varios antildeos terminoacute expandieacutendose

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 guiacutea y no como un meacutetodo formal y como resultado del creciente

intereacutes que habiacutea fuera del gobierno britaacutenico

Muchos de los conceptos principales de gestioacuten 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 lsquoUn

sistema de gestioacuten para el negocio de la informacioacutenrsquo)[4] [5] fueron precursores

claves Seguacuten IBM

A principios de los antildeos 1980 IBM documentoacute los conceptos originales de

Gestioacuten de Sistemas en una serie de cuatro voluacutemenes 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 tomoacute prestado de ellos hasta

tales extremos

16 Criacuteticas a ITIL

ITIL ha recibido criacuteticas de varios frentes Entre ellas

El hecho de que muchos defensores de ITIL parecen creer que es un

marco holiacutestico y completo para el gobierno de TI

Su tendencia a convertirla en una religioacuten

Como sentildeala Jan van Bon (autor y editor de muchas publicaciones de Gestioacuten

de Servicios de TI)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 9

Hay mucha confusioacuten sobre ITIL procedente de todo tipo de malentendidos

sobre su naturaleza ITIL como afirma la OGC es un conjunto de buenas

praacutecticas La OGC no afirma que dichas mejoras praacutecticas describan procesos

puros ni tampoco que ITIL sea un marco disentildeado como un modelo coherente

Eso es lo que la mayoriacutea de sus usuarios hacen de ella probablemente porque

tienen una gran necesidad de dicho modelo 3

El columnista CIO Magazine Dean Meyer tambieacuten ha expuesto algunos puntos

de vista cautelosos sobre ITIL incluyendo cinco trampas tiacutepicas tales como

laquoconvertirse en esclavo de definiciones desactualizadasraquo y laquodejar que ITIL se

convierta en religioacutenraquo Como Meyer sentildeala ITIL laquono describe el abanico

completo de procesos necesarios para ser liacutederes Se centra en [] gestionar

servicios actualesraquo4

La calidad de los voluacutemenes de la biblioteca se considera desigual Por

ejemplo Van Herwaarden y Grift sentildealan que laquola consistencia que

caracterizaba los procesos de soporte al servicio [] se pierde en gran medida

en los libros de entrega de servicioraquo5

17 Forma de uso de ITIL en Managed Services

ITIL postula que el servicio de soporte la administracioacuten y la operacioacuten se

realiza a traveacutes 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 Gestioacuten de Servicios de TI)

4 CIO Magazine Dean Meyer

5 Van Herwaarden y Grift

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 10

171 PROCESO DE MANEJO DE INCIDENTES

Su objetivo primordial es restablecer el servicio lo maacutes raacutepido posible para

evitar que el cliente se vea afectado esto se hace con la finalidad de que se

minimicen los efectos de la operacioacuten Se dice que el proveedor de debe de

encargar de que el cliente no debe percibir todas aquellas pequentildeas 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 baacutesicos que son propiedad monitoreo manejo de secuencias y

comunicacioacuten

En el proceso de manejo de incidentes vemos en la Figura 3 que se da como

primera etapa la deteccioacuten del incidente (es cuando el sistema presenta alguna

anomaliacutea 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 clasificacioacuten 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 seguacuten el manual de procedimientos para poder llegar a la

solucioacuten de una forma viable y eficiente) una vez que ya que se la dio una

solucioacuten al incidente por medio del manual de procedimientos se recurre a la

documentacioacuten y contabilizacioacuten del incidente para ver queacute tanta incidencia

tiene este caso finalmente se hace una evaluacioacuten para ver si efectivamente

se resolvioacute el incidente de forma satisfactoria y en supuesto de ser afirmativa

se cierra el incidente y el otro supuesto seria que de la solucioacuten que se planteo

no es lo suficientemente eficiente o acertada para que resuelva el problema y

se recurre a hacer una investigacioacuten y un diagnostico de la situacioacuten para ver

coacutemo es que se puede atacar el problema de frente y resolverlo una vez que

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 11

se tiene todo un contexto analizado se recurre a la ejecucioacuten de la propuesta

de solucioacuten del incidente y se hace un estudio para ver si el incidente es

recuperable o si es caso perdido (la mayoriacutea de los casos son recuperables

peo cuando el nivel de dantildeo es muy fuerte se da el caso de que se deacute por

perdido) y finamente se cierra el incidente y esta solucioacuten se documenta en

una base de datos a la que se le llama base del conocimiento o Knowledge

Data Base (aquiacute 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 maacutes faacutecil raacutepida y eficiente su resolucioacuten6

Figura 3 Proceso de manejo de incidentes

172 PROCESO DE MANEJO DE PROBLEMAS

El Objetivo de este proceso es prevenir y reducir al maacuteximo los incidentes y

esto nos lleva a una reduccioacuten en el nivel de incidencia Por otro lado nos

6 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtml

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 12

ayuda a proporcionar soluciones raacutepidas 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 daacutendole 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 estaacute relacionada con lo que es el control del problema y la segunda

es con el control del error7

En lo que respecta a la fase de control del problema primero se tiene que

identificar el problema en base a alguna sintomatologiacutea ya que tenemos este

antecedente pasamos a la clasificacioacuten 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

estaacuten en el manual de procedimientos y en caso de no ser conocido se tendriacutea

que hacer una fase de investigacioacuten para ver queacute es lo que genera el problema

y maacutes tarde hacer un diagnostico ya que tenemos un diagnoacutestico 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 solucioacuten

y finalmente se va a hacer una evaluacioacuten para ver si se resolvioacute el problema

de raiacutez En caso de que si se funcione esta solucioacuten se pasa a la

documentacioacuten

Con lo que respecta a la segunda fase del modelo el control del error se hace

por medio de una identificacioacuten 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 clasificacioacuten y se recurre a una evaluacioacuten de que tanto dantildeo genero

o puede llegar a generar el error esto con la finalidad de cuantificar los

desperfectos que podriacutea llegar a causar en caso de que el error prevalezca y

no se solucione posteriormente se hace la resolucioacuten o correccioacuten del error

7 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 13

(este puede deberse a varios aspectos configuraciones falta de seguridad

inconsistencia de datos etc) y este modelo tiene una fase muy difiacutecil que es

determinar que problemas estaacuten 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 pasariacutea si

cambio algunos de los datos en la configuracioacuten del sistema se tendriacutea que

afectar el sistema de manera uniforme para que siga en equilibrio y no esteacute

cambiado en algunas partes y en otras que se quede como estaba antes

Figura 4 Proceso de manejo de problemas

173 PROCESO DE MANEJO DE CONFIGURACIONES

Su objetivo es proveer con informacioacuten real y actualizada de lo que se tiene

configurado e instalado en cada sistema del cliente

Este proceso es de los maacutes complejos como muestra la Figura 5 ya que se

mueve bajo cuatro veacutertices que son administracioacuten de cambios administracioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 14

de liberaciones administracioacuten de configuraciones y la administracioacuten de

procesos diversos8

El nivel de complejidad de este modelo es alto ya que influyen muchas

variables y muchas de ellas son dinaacutemicas entonces al cambiar una o varias

de ellas se afecta el sistema en general lo que hace que sea muy difiacutecil de

manipular Aunque es lo maacutes parecido a la realidad porque nuestro entorno es

dinaacutemico y las decisiones de unos afectan a otros Por ejemplo en lo que

respecta a la administracioacuten de cambios vemos que se relaciona directamente

con la administracioacuten de incidentes y de problemas lo que conlleva una

planeacioacuten identificacioacuten control seguimiento del status verificacioacuten y

auditoria de configuraciones lo que hace que haya muchas variables

En otro ejemplo la implementacioacuten de cambios implica que se tiene que hacer

la liberacioacuten y distribucioacuten de nuevas versiones esto de da por una fase de

planeacioacuten identificacioacuten control revisioacuten del status verificacioacuten y auditoria y

puede depender de la administracioacuten de las capacidades ya que si no se

cuenta con el software o con el hardware esta fase no se podriacutea llevar a cabo y

asiacute se hariacutea con todos los niveles hasta llegar al cierre del control de cambios

8 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 15

Figura 5 Proceso de manejo de configuraciones

174 PROCESO DE CONTROL DE CAMBIOS

El objetivo de este proceso es reducir los riesgos tanto teacutecnicos econoacutemicos y

de tiempo al momento de la realizacioacuten de los cambios

La Figura 6 al parecer es muy faacutecil 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 objetivos9

Primero vemos que tenemos un registro y clasificacioacuten del cambio que se tiene

que hacer se pasa a la fase de monitoreo y planeacioacuten si el rendimiento es

9 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 16

satisfactorio se da la aprobacioacuten del cambio y en caso de que el rendimiento

sea malo se pasa a la fase de reingenieriacutea 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 estaacute

probado se da la autorizacioacuten e implementacioacuten ya implementado se ve que no

se hayan tenido desviaciones y se ajusta a las necesidades actuales que

tambieacuten se le considera como revisioacuten post-implementacioacuten

Figura 6 Proceso de control de cambios

175 PROCESO DE MANEJO DE ENTREGAS

Su objetivo es planear y controlar exitosamente la instalacioacuten 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 transicioacuten que se da de acuerdo

a los ambientes por los que se va dando la evolucioacuten del proyecto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 17

En lo que respecta al ambiente de desarrollo vemos en la Figura 7 que se tiene

que hacer la liberacioacuten de las poliacuteticas la liberacioacuten de la planeacioacuten el disentildeo

loacutegico de la infraestructura que se va a implementar y la adquisicioacuten de

software y hardware estaacuten 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 construccioacuten y

liberacioacuten de las configuraciones (nivel loacutegico) se hacen las pruebas para

establecer los acuerdos de aceptacioacuten se da la aceptacioacuten total de versiones y

de modelos se arranca la planeacioacuten y finalmente las pruebas y

comunicaciones y en lo que es el ambiente real vemos que se da la

distribucioacuten e instalacioacuten 10

En la etapa del ambiente real es la que se ve de forma maacutes concreta ya que

muchas veces no tenemos idea de todo lo que pasa hasta antes de la

instalacioacuten

En el proceso de entrega del servicio es el punto en el que el usuario hace uno

del servicio y no sabe que detraacutes del servicio que estaacute 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 maacutes 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 planeacioacuten monitoreo anaacutelisis y por un sin fin de pruebas con la intencioacuten

de que en caso de que algo no funcione se deacute en la fase de pruebas

controladas y no en la fase de pruebas en ambiente real donde el mayor

afectado es el cliente

10

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 18

Figura 7 Proceso de manejo de entregas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 19

CAPITULO II

GESTION DE VERSIONES

21 Introduccioacuten y Objetivos

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten 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 implementacioacuten de cualquier

cambio

La Gestioacuten de Cambios es la encargada de aprobar y supervisar todo el

proceso pero es tarea especiacutefica de la Gestioacuten de Versiones el disentildear poner a

prueba e instalar en el entorno de produccioacuten los cambios preestablecidos

Todo ello requiere de una cuidadosa planificacioacuten y coordinacioacuten con el resto

de procesos asociados a la Gestioacuten de Servicios TI

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 20

Entre los principales objetivos de la Gestioacuten de Versiones se incluyen

Establecer una poliacutetica de implementacioacuten de nuevas versiones de

hardware y software

Implementar las nuevas versiones de software y hardware en el entorno

de produccioacuten tras su verificacioacuten en un entorno realista de pruebas

Garantizar que el proceso de cambio cumpla las especificaciones de la

RFC correspondiente

Asegurar en colaboracioacuten con la Gestioacuten de Cambios y

Configuraciones que todos los cambios se ven correctamente reflejados

en la CMDB

Archivar copias ideacutenticas del software en produccioacuten asiacute como de toda

su documentacioacuten asociada en la Biblioteca de Software Definitivo

(DSL)

Mantener actualizado el Depoacutesito de Hardware Definitivo (DHS)

22 Beneficios y Dificultades

Los beneficios de una correcta Gestioacuten 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 nuacutemero de incidentes por incompatibilidades con otro

software o hardware instalado

El proceso de pruebas asociado no soacutelo permite asegurar la calidad del

software y hardware a instalar sino que tambieacuten permite conocer la

opinioacuten 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 nuacutemero de copias de software ilegales

Control centralizado del software y hardware desplegado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 21

Proteccioacuten contra virus y problemas asociados a versiones de software

incontroladas

Las principales dificultades con las que topa la Gestioacuten de Versiones son

No existe una clara asignacioacuten de responsabilidades yo la organizacioacuten

TI no acepta la figura dominante de la Gestioacuten de Versiones en todo el

proceso de implementacioacuten 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 centralizacioacuten del

proceso de cambio Es habitual que existan reticencias a adoptar

sistemas estandarizados en toda la organizacioacuten sobre todo cuando

eacutesta no ha sido la poliacutetica tradicional de la misma

Se realizan cambios sin tener en cuenta a la Gestioacuten de Versiones

argumentado que estos soacutelo son responsabilidad de un determinado

grupo de trabajo o que su urgencia requeriacutea de ello

Hay resistencias a aceptar posibles planes de back-out Ciertos

entornos de produccioacuten pueden elegir ignorar lo problemas que una

nueva versioacuten puede provocar en otras aacutereas y resistirse a volver a la

uacuteltima versioacuten estable

La implementacioacuten sincronizada de versiones en entornos altamente

distribuidos

La solucioacuten a estos problemas pasa por

Un firme compromiso de la organizacioacuten con la Gestioacuten de Versiones y

sus responsables

Un adecuado plan de comunicacioacuten que informe a todos los

responsables y usuarios de la organizacioacuten TI de las ventajas de una

correcta gestioacuten de todo el proceso de cambio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 22

Una versioacuten es un grupo de CIs de nueva creacioacuten o modificados que han sido

validados para su instalacioacuten en el entorno de produccioacuten Las especificaciones

funcionales y teacutecnicas de una versioacuten estaacuten determinadas en la RFC

correspondiente

23 Clasificacioacuten de las Versiones

Las versiones pueden clasificarse seguacuten 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 caracteriacutesticas teacutecnicas etc

Versiones menores que suelen implicar la correccioacuten 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 raacutepida

un error conocido

Como pueden llegar a existir muacuteltiples versiones es conveniente definir una

referencia o coacutedigo que los identifique uniacutevocamente El sistema

universalmente aceptado es

Versiones mayores 10 20 etc

Versiones menores 11 12 13 etc

Versiones de emergencia 111 112 etc

Aunque en algunos casos esta clasificacioacuten se refina auacuten maacutes (vea por

ejemplo en la ayuda la versioacuten de su navegador)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 23

En su ciclo de vida una versioacuten puede encontrase en diversos estados

desarrollo pruebas produccioacuten y archivado11

En la Figura 8 nos ilustra graacuteficamente la evolucioacuten temporal de una versioacuten

Figura 8 Evolucioacuten temporal de una versioacuten

El despliegue de nuevas versiones puede realizarse de diferentes maneras y

es responsabilidad de la Gestioacuten de Cambios el determinar la forma maacutes

conveniente de hacerlo Entre las opciones maacutes habituales cabe contar

Versioacuten delta soacutelo se testean e instalan los elementos modificados

Esta opcioacuten tiene como ventaja su mayor simplicidad pero conlleva el

peligro de que puedan aparecer problemas e incompatibilidades en el

entorno de produccioacuten

Versioacuten completa Se distribuyen todos los elementos afectados ya

hayan sido modificados o no Aunque esta opcioacuten es obviamente maacutes

trabajosa es maacutes improbable que se generen incidentes tras la

instalacioacuten si se han realizado las pruebas pertinentes

11

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 24

Paquete de Versiones La Gestioacuten 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 opcioacuten es obligada por incompatibilidades entre una nueva

versioacuten con software o hardware previamente instalado Pensemos por

ejemplo en la migracioacuten a un nuevo sistema operativo que requiere

hardware maacutes avanzado yo nuevos versiones de los programas

ofimaacuteticos

24 Visioacuten General

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI12

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten de Versiones se resumen

sucintamente en la siguiente Figura 9

12

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 25

Figura 9 Visioacuten General de la Gestioacuten de Versiones

25 Planificacioacuten

Es crucial establecer un marco general para el lanzamiento de nuevas

versiones que fije una metodologiacutea 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

especiacuteficos que tomen en cuenta las peculiaridades de cada caso

A la hora de planificar correctamente el lanzamiento de una nueva versioacuten se

deben de tomar en cuenta los siguientes factores

Coacutemo puede afectar la nueva versioacuten a otras aacutereas del entramado TI

Queacute CIs se veraacuten directa o indirectamente implicados durante y tras el

lanzamiento de la nueva versioacuten

Coacutemo ha de construirse el entorno de pruebas para que eacuteste sea fiel

reflejo del entorno de produccioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 26

Queacute planes de back-out son necesarios

Coacutemo y cuaacutendo se deben implementar los planes de back-out para

minimizar el posible impacto negativo sobre el servicio y la integridad del

sistema TI

Cuaacuteles son los recursos humanos y teacutecnicos necesarios para llevar a

cabo la implementacioacuten de la nueva versioacuten con garantiacuteas de eacutexito

Quieacutenes seraacuten los responsables directos en las diferentes etapas del

proceso

Queacute planes de comunicacioacuten yo formacioacuten deben desarrollarse para

que los usuarios esteacuten puntualmente informados y puedan percibir la

nueva versioacuten como una mejora

Queacute tipo de despliegue es el maacutes adecuado completo delta

sincronizado en todas los emplazamientos gradual

Cuaacutel es la vida media uacutetil esperada de la nueva versioacuten

Queacute impacto puede tener el proceso de lanzamiento de la nueva versioacuten

en la calidad del servicio

Si es posible establecer meacutetricas precisas que determinen el grado de

eacutexito del lanzamiento de la nueva versioacuten

26 Desarrollo

La Gestioacuten de Versiones es la encargada del disentildeo y construccioacuten de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes

A veces el desarrollo se realizara en la casa y muchas otras requeriraacute la

participacioacuten de proveedores externos En este segundo caso la tarea de la

Gestioacuten de Versiones seraacute la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC Asimismo la Gestioacuten de Versiones seraacute la responsable de todo el

proceso de configuracioacuten necesario

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

Parte integrante del desarrollo lo componen los planes de back-out asociados

Estos tendraacuten que tomar en cuenta la disponibilidad acordada con los clientes

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

Es importante que las pruebas incluyan los planes de back-out para

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

Que meacutetricas determinan la puesta en marcha de los planes de back-out

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

informada por el Service Desk de los comentarios quejas incidentes etc que

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

recibidas y que se tomen las medidas correctivas necesarias para minimizar el

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

Es frecuente y a su vez un grave error que cuando se aborden cuestiones de

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

Es inuacutetil disponer de un sofisticado servicio TI si los usuarios debido a una

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

remotos mediante moacutedulos de e-learning sobre el funcionamiento de la

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 7: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 7

la comprensioacuten de la terminologiacutea propia de ITIL Estaacute destinado a

aquellas personas que deseen conocer las buenas praacutecticas

especificadas en ITIL

2 Practitioners Certificate (Certificado de Responsable) destinado a

quienes tienen responsabilidad en el disentildeo de procesos de

administracioacuten de departamentos de tecnologiacuteas de la informacioacuten y en

la planificacioacuten de las actividades asociadas a los procesos

3 Managers Certificate (Certificado de Director) garantiza que quien lo

posee dispone de profundos conocimientos en todas las materias

relacionadas con la administracioacuten de departamentos de tecnologiacuteas de

la informacioacuten y lo habilita para dirigir la implantacioacuten de soluciones

basadas en ITIL

No es posible certificar una organizacioacuten o sistema de gestioacuten como laquoconforme

a ITILraquo pero una organizacioacuten que haya implementado las guiacuteas de ITIL sobre

Gestioacuten de los Servicios de TI puede lograr certificarse bajo la ISOIEC 200002

La versioacuten 3 de ITIL que aparecioacute en junio de 2007 cambioacute 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)

15 Historia y precursores de ITIL

Lo que actualmente se conoce como ITIL versioacuten 1 desarrollada bajo el

auspicio de la CCTA se tituloacute Government Information Technology

Infrastructure Method (lsquoMeacutetodo de Infraestructura de la Tecnologiacutea de 2 httpeswikipediaorgwikiInformation_Technology_Infrastructure_Library

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 8

Informacioacuten del Gobiernorsquo GITM) y durante varios antildeos terminoacute expandieacutendose

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 guiacutea y no como un meacutetodo formal y como resultado del creciente

intereacutes que habiacutea fuera del gobierno britaacutenico

Muchos de los conceptos principales de gestioacuten 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 lsquoUn

sistema de gestioacuten para el negocio de la informacioacutenrsquo)[4] [5] fueron precursores

claves Seguacuten IBM

A principios de los antildeos 1980 IBM documentoacute los conceptos originales de

Gestioacuten de Sistemas en una serie de cuatro voluacutemenes 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 tomoacute prestado de ellos hasta

tales extremos

16 Criacuteticas a ITIL

ITIL ha recibido criacuteticas de varios frentes Entre ellas

El hecho de que muchos defensores de ITIL parecen creer que es un

marco holiacutestico y completo para el gobierno de TI

Su tendencia a convertirla en una religioacuten

Como sentildeala Jan van Bon (autor y editor de muchas publicaciones de Gestioacuten

de Servicios de TI)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 9

Hay mucha confusioacuten sobre ITIL procedente de todo tipo de malentendidos

sobre su naturaleza ITIL como afirma la OGC es un conjunto de buenas

praacutecticas La OGC no afirma que dichas mejoras praacutecticas describan procesos

puros ni tampoco que ITIL sea un marco disentildeado como un modelo coherente

Eso es lo que la mayoriacutea de sus usuarios hacen de ella probablemente porque

tienen una gran necesidad de dicho modelo 3

El columnista CIO Magazine Dean Meyer tambieacuten ha expuesto algunos puntos

de vista cautelosos sobre ITIL incluyendo cinco trampas tiacutepicas tales como

laquoconvertirse en esclavo de definiciones desactualizadasraquo y laquodejar que ITIL se

convierta en religioacutenraquo Como Meyer sentildeala ITIL laquono describe el abanico

completo de procesos necesarios para ser liacutederes Se centra en [] gestionar

servicios actualesraquo4

La calidad de los voluacutemenes de la biblioteca se considera desigual Por

ejemplo Van Herwaarden y Grift sentildealan que laquola consistencia que

caracterizaba los procesos de soporte al servicio [] se pierde en gran medida

en los libros de entrega de servicioraquo5

17 Forma de uso de ITIL en Managed Services

ITIL postula que el servicio de soporte la administracioacuten y la operacioacuten se

realiza a traveacutes 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 Gestioacuten de Servicios de TI)

4 CIO Magazine Dean Meyer

5 Van Herwaarden y Grift

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 10

171 PROCESO DE MANEJO DE INCIDENTES

Su objetivo primordial es restablecer el servicio lo maacutes raacutepido posible para

evitar que el cliente se vea afectado esto se hace con la finalidad de que se

minimicen los efectos de la operacioacuten Se dice que el proveedor de debe de

encargar de que el cliente no debe percibir todas aquellas pequentildeas 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 baacutesicos que son propiedad monitoreo manejo de secuencias y

comunicacioacuten

En el proceso de manejo de incidentes vemos en la Figura 3 que se da como

primera etapa la deteccioacuten del incidente (es cuando el sistema presenta alguna

anomaliacutea 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 clasificacioacuten 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 seguacuten el manual de procedimientos para poder llegar a la

solucioacuten de una forma viable y eficiente) una vez que ya que se la dio una

solucioacuten al incidente por medio del manual de procedimientos se recurre a la

documentacioacuten y contabilizacioacuten del incidente para ver queacute tanta incidencia

tiene este caso finalmente se hace una evaluacioacuten para ver si efectivamente

se resolvioacute el incidente de forma satisfactoria y en supuesto de ser afirmativa

se cierra el incidente y el otro supuesto seria que de la solucioacuten que se planteo

no es lo suficientemente eficiente o acertada para que resuelva el problema y

se recurre a hacer una investigacioacuten y un diagnostico de la situacioacuten para ver

coacutemo es que se puede atacar el problema de frente y resolverlo una vez que

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 11

se tiene todo un contexto analizado se recurre a la ejecucioacuten de la propuesta

de solucioacuten del incidente y se hace un estudio para ver si el incidente es

recuperable o si es caso perdido (la mayoriacutea de los casos son recuperables

peo cuando el nivel de dantildeo es muy fuerte se da el caso de que se deacute por

perdido) y finamente se cierra el incidente y esta solucioacuten se documenta en

una base de datos a la que se le llama base del conocimiento o Knowledge

Data Base (aquiacute 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 maacutes faacutecil raacutepida y eficiente su resolucioacuten6

Figura 3 Proceso de manejo de incidentes

172 PROCESO DE MANEJO DE PROBLEMAS

El Objetivo de este proceso es prevenir y reducir al maacuteximo los incidentes y

esto nos lleva a una reduccioacuten en el nivel de incidencia Por otro lado nos

6 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtml

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 12

ayuda a proporcionar soluciones raacutepidas 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 daacutendole 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 estaacute relacionada con lo que es el control del problema y la segunda

es con el control del error7

En lo que respecta a la fase de control del problema primero se tiene que

identificar el problema en base a alguna sintomatologiacutea ya que tenemos este

antecedente pasamos a la clasificacioacuten 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

estaacuten en el manual de procedimientos y en caso de no ser conocido se tendriacutea

que hacer una fase de investigacioacuten para ver queacute es lo que genera el problema

y maacutes tarde hacer un diagnostico ya que tenemos un diagnoacutestico 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 solucioacuten

y finalmente se va a hacer una evaluacioacuten para ver si se resolvioacute el problema

de raiacutez En caso de que si se funcione esta solucioacuten se pasa a la

documentacioacuten

Con lo que respecta a la segunda fase del modelo el control del error se hace

por medio de una identificacioacuten 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 clasificacioacuten y se recurre a una evaluacioacuten de que tanto dantildeo genero

o puede llegar a generar el error esto con la finalidad de cuantificar los

desperfectos que podriacutea llegar a causar en caso de que el error prevalezca y

no se solucione posteriormente se hace la resolucioacuten o correccioacuten del error

7 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 13

(este puede deberse a varios aspectos configuraciones falta de seguridad

inconsistencia de datos etc) y este modelo tiene una fase muy difiacutecil que es

determinar que problemas estaacuten 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 pasariacutea si

cambio algunos de los datos en la configuracioacuten del sistema se tendriacutea que

afectar el sistema de manera uniforme para que siga en equilibrio y no esteacute

cambiado en algunas partes y en otras que se quede como estaba antes

Figura 4 Proceso de manejo de problemas

173 PROCESO DE MANEJO DE CONFIGURACIONES

Su objetivo es proveer con informacioacuten real y actualizada de lo que se tiene

configurado e instalado en cada sistema del cliente

Este proceso es de los maacutes complejos como muestra la Figura 5 ya que se

mueve bajo cuatro veacutertices que son administracioacuten de cambios administracioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 14

de liberaciones administracioacuten de configuraciones y la administracioacuten de

procesos diversos8

El nivel de complejidad de este modelo es alto ya que influyen muchas

variables y muchas de ellas son dinaacutemicas entonces al cambiar una o varias

de ellas se afecta el sistema en general lo que hace que sea muy difiacutecil de

manipular Aunque es lo maacutes parecido a la realidad porque nuestro entorno es

dinaacutemico y las decisiones de unos afectan a otros Por ejemplo en lo que

respecta a la administracioacuten de cambios vemos que se relaciona directamente

con la administracioacuten de incidentes y de problemas lo que conlleva una

planeacioacuten identificacioacuten control seguimiento del status verificacioacuten y

auditoria de configuraciones lo que hace que haya muchas variables

En otro ejemplo la implementacioacuten de cambios implica que se tiene que hacer

la liberacioacuten y distribucioacuten de nuevas versiones esto de da por una fase de

planeacioacuten identificacioacuten control revisioacuten del status verificacioacuten y auditoria y

puede depender de la administracioacuten de las capacidades ya que si no se

cuenta con el software o con el hardware esta fase no se podriacutea llevar a cabo y

asiacute se hariacutea con todos los niveles hasta llegar al cierre del control de cambios

8 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 15

Figura 5 Proceso de manejo de configuraciones

174 PROCESO DE CONTROL DE CAMBIOS

El objetivo de este proceso es reducir los riesgos tanto teacutecnicos econoacutemicos y

de tiempo al momento de la realizacioacuten de los cambios

La Figura 6 al parecer es muy faacutecil 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 objetivos9

Primero vemos que tenemos un registro y clasificacioacuten del cambio que se tiene

que hacer se pasa a la fase de monitoreo y planeacioacuten si el rendimiento es

9 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 16

satisfactorio se da la aprobacioacuten del cambio y en caso de que el rendimiento

sea malo se pasa a la fase de reingenieriacutea 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 estaacute

probado se da la autorizacioacuten e implementacioacuten ya implementado se ve que no

se hayan tenido desviaciones y se ajusta a las necesidades actuales que

tambieacuten se le considera como revisioacuten post-implementacioacuten

Figura 6 Proceso de control de cambios

175 PROCESO DE MANEJO DE ENTREGAS

Su objetivo es planear y controlar exitosamente la instalacioacuten 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 transicioacuten que se da de acuerdo

a los ambientes por los que se va dando la evolucioacuten del proyecto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 17

En lo que respecta al ambiente de desarrollo vemos en la Figura 7 que se tiene

que hacer la liberacioacuten de las poliacuteticas la liberacioacuten de la planeacioacuten el disentildeo

loacutegico de la infraestructura que se va a implementar y la adquisicioacuten de

software y hardware estaacuten 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 construccioacuten y

liberacioacuten de las configuraciones (nivel loacutegico) se hacen las pruebas para

establecer los acuerdos de aceptacioacuten se da la aceptacioacuten total de versiones y

de modelos se arranca la planeacioacuten y finalmente las pruebas y

comunicaciones y en lo que es el ambiente real vemos que se da la

distribucioacuten e instalacioacuten 10

En la etapa del ambiente real es la que se ve de forma maacutes concreta ya que

muchas veces no tenemos idea de todo lo que pasa hasta antes de la

instalacioacuten

En el proceso de entrega del servicio es el punto en el que el usuario hace uno

del servicio y no sabe que detraacutes del servicio que estaacute 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 maacutes 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 planeacioacuten monitoreo anaacutelisis y por un sin fin de pruebas con la intencioacuten

de que en caso de que algo no funcione se deacute en la fase de pruebas

controladas y no en la fase de pruebas en ambiente real donde el mayor

afectado es el cliente

10

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 18

Figura 7 Proceso de manejo de entregas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 19

CAPITULO II

GESTION DE VERSIONES

21 Introduccioacuten y Objetivos

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten 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 implementacioacuten de cualquier

cambio

La Gestioacuten de Cambios es la encargada de aprobar y supervisar todo el

proceso pero es tarea especiacutefica de la Gestioacuten de Versiones el disentildear poner a

prueba e instalar en el entorno de produccioacuten los cambios preestablecidos

Todo ello requiere de una cuidadosa planificacioacuten y coordinacioacuten con el resto

de procesos asociados a la Gestioacuten de Servicios TI

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 20

Entre los principales objetivos de la Gestioacuten de Versiones se incluyen

Establecer una poliacutetica de implementacioacuten de nuevas versiones de

hardware y software

Implementar las nuevas versiones de software y hardware en el entorno

de produccioacuten tras su verificacioacuten en un entorno realista de pruebas

Garantizar que el proceso de cambio cumpla las especificaciones de la

RFC correspondiente

Asegurar en colaboracioacuten con la Gestioacuten de Cambios y

Configuraciones que todos los cambios se ven correctamente reflejados

en la CMDB

Archivar copias ideacutenticas del software en produccioacuten asiacute como de toda

su documentacioacuten asociada en la Biblioteca de Software Definitivo

(DSL)

Mantener actualizado el Depoacutesito de Hardware Definitivo (DHS)

22 Beneficios y Dificultades

Los beneficios de una correcta Gestioacuten 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 nuacutemero de incidentes por incompatibilidades con otro

software o hardware instalado

El proceso de pruebas asociado no soacutelo permite asegurar la calidad del

software y hardware a instalar sino que tambieacuten permite conocer la

opinioacuten 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 nuacutemero de copias de software ilegales

Control centralizado del software y hardware desplegado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 21

Proteccioacuten contra virus y problemas asociados a versiones de software

incontroladas

Las principales dificultades con las que topa la Gestioacuten de Versiones son

No existe una clara asignacioacuten de responsabilidades yo la organizacioacuten

TI no acepta la figura dominante de la Gestioacuten de Versiones en todo el

proceso de implementacioacuten 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 centralizacioacuten del

proceso de cambio Es habitual que existan reticencias a adoptar

sistemas estandarizados en toda la organizacioacuten sobre todo cuando

eacutesta no ha sido la poliacutetica tradicional de la misma

Se realizan cambios sin tener en cuenta a la Gestioacuten de Versiones

argumentado que estos soacutelo son responsabilidad de un determinado

grupo de trabajo o que su urgencia requeriacutea de ello

Hay resistencias a aceptar posibles planes de back-out Ciertos

entornos de produccioacuten pueden elegir ignorar lo problemas que una

nueva versioacuten puede provocar en otras aacutereas y resistirse a volver a la

uacuteltima versioacuten estable

La implementacioacuten sincronizada de versiones en entornos altamente

distribuidos

La solucioacuten a estos problemas pasa por

Un firme compromiso de la organizacioacuten con la Gestioacuten de Versiones y

sus responsables

Un adecuado plan de comunicacioacuten que informe a todos los

responsables y usuarios de la organizacioacuten TI de las ventajas de una

correcta gestioacuten de todo el proceso de cambio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 22

Una versioacuten es un grupo de CIs de nueva creacioacuten o modificados que han sido

validados para su instalacioacuten en el entorno de produccioacuten Las especificaciones

funcionales y teacutecnicas de una versioacuten estaacuten determinadas en la RFC

correspondiente

23 Clasificacioacuten de las Versiones

Las versiones pueden clasificarse seguacuten 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 caracteriacutesticas teacutecnicas etc

Versiones menores que suelen implicar la correccioacuten 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 raacutepida

un error conocido

Como pueden llegar a existir muacuteltiples versiones es conveniente definir una

referencia o coacutedigo que los identifique uniacutevocamente El sistema

universalmente aceptado es

Versiones mayores 10 20 etc

Versiones menores 11 12 13 etc

Versiones de emergencia 111 112 etc

Aunque en algunos casos esta clasificacioacuten se refina auacuten maacutes (vea por

ejemplo en la ayuda la versioacuten de su navegador)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 23

En su ciclo de vida una versioacuten puede encontrase en diversos estados

desarrollo pruebas produccioacuten y archivado11

En la Figura 8 nos ilustra graacuteficamente la evolucioacuten temporal de una versioacuten

Figura 8 Evolucioacuten temporal de una versioacuten

El despliegue de nuevas versiones puede realizarse de diferentes maneras y

es responsabilidad de la Gestioacuten de Cambios el determinar la forma maacutes

conveniente de hacerlo Entre las opciones maacutes habituales cabe contar

Versioacuten delta soacutelo se testean e instalan los elementos modificados

Esta opcioacuten tiene como ventaja su mayor simplicidad pero conlleva el

peligro de que puedan aparecer problemas e incompatibilidades en el

entorno de produccioacuten

Versioacuten completa Se distribuyen todos los elementos afectados ya

hayan sido modificados o no Aunque esta opcioacuten es obviamente maacutes

trabajosa es maacutes improbable que se generen incidentes tras la

instalacioacuten si se han realizado las pruebas pertinentes

11

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 24

Paquete de Versiones La Gestioacuten 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 opcioacuten es obligada por incompatibilidades entre una nueva

versioacuten con software o hardware previamente instalado Pensemos por

ejemplo en la migracioacuten a un nuevo sistema operativo que requiere

hardware maacutes avanzado yo nuevos versiones de los programas

ofimaacuteticos

24 Visioacuten General

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI12

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten de Versiones se resumen

sucintamente en la siguiente Figura 9

12

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 25

Figura 9 Visioacuten General de la Gestioacuten de Versiones

25 Planificacioacuten

Es crucial establecer un marco general para el lanzamiento de nuevas

versiones que fije una metodologiacutea 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

especiacuteficos que tomen en cuenta las peculiaridades de cada caso

A la hora de planificar correctamente el lanzamiento de una nueva versioacuten se

deben de tomar en cuenta los siguientes factores

Coacutemo puede afectar la nueva versioacuten a otras aacutereas del entramado TI

Queacute CIs se veraacuten directa o indirectamente implicados durante y tras el

lanzamiento de la nueva versioacuten

Coacutemo ha de construirse el entorno de pruebas para que eacuteste sea fiel

reflejo del entorno de produccioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 26

Queacute planes de back-out son necesarios

Coacutemo y cuaacutendo se deben implementar los planes de back-out para

minimizar el posible impacto negativo sobre el servicio y la integridad del

sistema TI

Cuaacuteles son los recursos humanos y teacutecnicos necesarios para llevar a

cabo la implementacioacuten de la nueva versioacuten con garantiacuteas de eacutexito

Quieacutenes seraacuten los responsables directos en las diferentes etapas del

proceso

Queacute planes de comunicacioacuten yo formacioacuten deben desarrollarse para

que los usuarios esteacuten puntualmente informados y puedan percibir la

nueva versioacuten como una mejora

Queacute tipo de despliegue es el maacutes adecuado completo delta

sincronizado en todas los emplazamientos gradual

Cuaacutel es la vida media uacutetil esperada de la nueva versioacuten

Queacute impacto puede tener el proceso de lanzamiento de la nueva versioacuten

en la calidad del servicio

Si es posible establecer meacutetricas precisas que determinen el grado de

eacutexito del lanzamiento de la nueva versioacuten

26 Desarrollo

La Gestioacuten de Versiones es la encargada del disentildeo y construccioacuten de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes

A veces el desarrollo se realizara en la casa y muchas otras requeriraacute la

participacioacuten de proveedores externos En este segundo caso la tarea de la

Gestioacuten de Versiones seraacute la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC Asimismo la Gestioacuten de Versiones seraacute la responsable de todo el

proceso de configuracioacuten necesario

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

Parte integrante del desarrollo lo componen los planes de back-out asociados

Estos tendraacuten que tomar en cuenta la disponibilidad acordada con los clientes

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

Es importante que las pruebas incluyan los planes de back-out para

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

Que meacutetricas determinan la puesta en marcha de los planes de back-out

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

informada por el Service Desk de los comentarios quejas incidentes etc que

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

recibidas y que se tomen las medidas correctivas necesarias para minimizar el

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

Es frecuente y a su vez un grave error que cuando se aborden cuestiones de

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

Es inuacutetil disponer de un sofisticado servicio TI si los usuarios debido a una

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

remotos mediante moacutedulos de e-learning sobre el funcionamiento de la

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 8: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 8

Informacioacuten del Gobiernorsquo GITM) y durante varios antildeos terminoacute expandieacutendose

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 guiacutea y no como un meacutetodo formal y como resultado del creciente

intereacutes que habiacutea fuera del gobierno britaacutenico

Muchos de los conceptos principales de gestioacuten 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 lsquoUn

sistema de gestioacuten para el negocio de la informacioacutenrsquo)[4] [5] fueron precursores

claves Seguacuten IBM

A principios de los antildeos 1980 IBM documentoacute los conceptos originales de

Gestioacuten de Sistemas en una serie de cuatro voluacutemenes 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 tomoacute prestado de ellos hasta

tales extremos

16 Criacuteticas a ITIL

ITIL ha recibido criacuteticas de varios frentes Entre ellas

El hecho de que muchos defensores de ITIL parecen creer que es un

marco holiacutestico y completo para el gobierno de TI

Su tendencia a convertirla en una religioacuten

Como sentildeala Jan van Bon (autor y editor de muchas publicaciones de Gestioacuten

de Servicios de TI)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 9

Hay mucha confusioacuten sobre ITIL procedente de todo tipo de malentendidos

sobre su naturaleza ITIL como afirma la OGC es un conjunto de buenas

praacutecticas La OGC no afirma que dichas mejoras praacutecticas describan procesos

puros ni tampoco que ITIL sea un marco disentildeado como un modelo coherente

Eso es lo que la mayoriacutea de sus usuarios hacen de ella probablemente porque

tienen una gran necesidad de dicho modelo 3

El columnista CIO Magazine Dean Meyer tambieacuten ha expuesto algunos puntos

de vista cautelosos sobre ITIL incluyendo cinco trampas tiacutepicas tales como

laquoconvertirse en esclavo de definiciones desactualizadasraquo y laquodejar que ITIL se

convierta en religioacutenraquo Como Meyer sentildeala ITIL laquono describe el abanico

completo de procesos necesarios para ser liacutederes Se centra en [] gestionar

servicios actualesraquo4

La calidad de los voluacutemenes de la biblioteca se considera desigual Por

ejemplo Van Herwaarden y Grift sentildealan que laquola consistencia que

caracterizaba los procesos de soporte al servicio [] se pierde en gran medida

en los libros de entrega de servicioraquo5

17 Forma de uso de ITIL en Managed Services

ITIL postula que el servicio de soporte la administracioacuten y la operacioacuten se

realiza a traveacutes 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 Gestioacuten de Servicios de TI)

4 CIO Magazine Dean Meyer

5 Van Herwaarden y Grift

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 10

171 PROCESO DE MANEJO DE INCIDENTES

Su objetivo primordial es restablecer el servicio lo maacutes raacutepido posible para

evitar que el cliente se vea afectado esto se hace con la finalidad de que se

minimicen los efectos de la operacioacuten Se dice que el proveedor de debe de

encargar de que el cliente no debe percibir todas aquellas pequentildeas 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 baacutesicos que son propiedad monitoreo manejo de secuencias y

comunicacioacuten

En el proceso de manejo de incidentes vemos en la Figura 3 que se da como

primera etapa la deteccioacuten del incidente (es cuando el sistema presenta alguna

anomaliacutea 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 clasificacioacuten 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 seguacuten el manual de procedimientos para poder llegar a la

solucioacuten de una forma viable y eficiente) una vez que ya que se la dio una

solucioacuten al incidente por medio del manual de procedimientos se recurre a la

documentacioacuten y contabilizacioacuten del incidente para ver queacute tanta incidencia

tiene este caso finalmente se hace una evaluacioacuten para ver si efectivamente

se resolvioacute el incidente de forma satisfactoria y en supuesto de ser afirmativa

se cierra el incidente y el otro supuesto seria que de la solucioacuten que se planteo

no es lo suficientemente eficiente o acertada para que resuelva el problema y

se recurre a hacer una investigacioacuten y un diagnostico de la situacioacuten para ver

coacutemo es que se puede atacar el problema de frente y resolverlo una vez que

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 11

se tiene todo un contexto analizado se recurre a la ejecucioacuten de la propuesta

de solucioacuten del incidente y se hace un estudio para ver si el incidente es

recuperable o si es caso perdido (la mayoriacutea de los casos son recuperables

peo cuando el nivel de dantildeo es muy fuerte se da el caso de que se deacute por

perdido) y finamente se cierra el incidente y esta solucioacuten se documenta en

una base de datos a la que se le llama base del conocimiento o Knowledge

Data Base (aquiacute 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 maacutes faacutecil raacutepida y eficiente su resolucioacuten6

Figura 3 Proceso de manejo de incidentes

172 PROCESO DE MANEJO DE PROBLEMAS

El Objetivo de este proceso es prevenir y reducir al maacuteximo los incidentes y

esto nos lleva a una reduccioacuten en el nivel de incidencia Por otro lado nos

6 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtml

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 12

ayuda a proporcionar soluciones raacutepidas 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 daacutendole 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 estaacute relacionada con lo que es el control del problema y la segunda

es con el control del error7

En lo que respecta a la fase de control del problema primero se tiene que

identificar el problema en base a alguna sintomatologiacutea ya que tenemos este

antecedente pasamos a la clasificacioacuten 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

estaacuten en el manual de procedimientos y en caso de no ser conocido se tendriacutea

que hacer una fase de investigacioacuten para ver queacute es lo que genera el problema

y maacutes tarde hacer un diagnostico ya que tenemos un diagnoacutestico 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 solucioacuten

y finalmente se va a hacer una evaluacioacuten para ver si se resolvioacute el problema

de raiacutez En caso de que si se funcione esta solucioacuten se pasa a la

documentacioacuten

Con lo que respecta a la segunda fase del modelo el control del error se hace

por medio de una identificacioacuten 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 clasificacioacuten y se recurre a una evaluacioacuten de que tanto dantildeo genero

o puede llegar a generar el error esto con la finalidad de cuantificar los

desperfectos que podriacutea llegar a causar en caso de que el error prevalezca y

no se solucione posteriormente se hace la resolucioacuten o correccioacuten del error

7 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 13

(este puede deberse a varios aspectos configuraciones falta de seguridad

inconsistencia de datos etc) y este modelo tiene una fase muy difiacutecil que es

determinar que problemas estaacuten 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 pasariacutea si

cambio algunos de los datos en la configuracioacuten del sistema se tendriacutea que

afectar el sistema de manera uniforme para que siga en equilibrio y no esteacute

cambiado en algunas partes y en otras que se quede como estaba antes

Figura 4 Proceso de manejo de problemas

173 PROCESO DE MANEJO DE CONFIGURACIONES

Su objetivo es proveer con informacioacuten real y actualizada de lo que se tiene

configurado e instalado en cada sistema del cliente

Este proceso es de los maacutes complejos como muestra la Figura 5 ya que se

mueve bajo cuatro veacutertices que son administracioacuten de cambios administracioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 14

de liberaciones administracioacuten de configuraciones y la administracioacuten de

procesos diversos8

El nivel de complejidad de este modelo es alto ya que influyen muchas

variables y muchas de ellas son dinaacutemicas entonces al cambiar una o varias

de ellas se afecta el sistema en general lo que hace que sea muy difiacutecil de

manipular Aunque es lo maacutes parecido a la realidad porque nuestro entorno es

dinaacutemico y las decisiones de unos afectan a otros Por ejemplo en lo que

respecta a la administracioacuten de cambios vemos que se relaciona directamente

con la administracioacuten de incidentes y de problemas lo que conlleva una

planeacioacuten identificacioacuten control seguimiento del status verificacioacuten y

auditoria de configuraciones lo que hace que haya muchas variables

En otro ejemplo la implementacioacuten de cambios implica que se tiene que hacer

la liberacioacuten y distribucioacuten de nuevas versiones esto de da por una fase de

planeacioacuten identificacioacuten control revisioacuten del status verificacioacuten y auditoria y

puede depender de la administracioacuten de las capacidades ya que si no se

cuenta con el software o con el hardware esta fase no se podriacutea llevar a cabo y

asiacute se hariacutea con todos los niveles hasta llegar al cierre del control de cambios

8 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 15

Figura 5 Proceso de manejo de configuraciones

174 PROCESO DE CONTROL DE CAMBIOS

El objetivo de este proceso es reducir los riesgos tanto teacutecnicos econoacutemicos y

de tiempo al momento de la realizacioacuten de los cambios

La Figura 6 al parecer es muy faacutecil 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 objetivos9

Primero vemos que tenemos un registro y clasificacioacuten del cambio que se tiene

que hacer se pasa a la fase de monitoreo y planeacioacuten si el rendimiento es

9 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 16

satisfactorio se da la aprobacioacuten del cambio y en caso de que el rendimiento

sea malo se pasa a la fase de reingenieriacutea 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 estaacute

probado se da la autorizacioacuten e implementacioacuten ya implementado se ve que no

se hayan tenido desviaciones y se ajusta a las necesidades actuales que

tambieacuten se le considera como revisioacuten post-implementacioacuten

Figura 6 Proceso de control de cambios

175 PROCESO DE MANEJO DE ENTREGAS

Su objetivo es planear y controlar exitosamente la instalacioacuten 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 transicioacuten que se da de acuerdo

a los ambientes por los que se va dando la evolucioacuten del proyecto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 17

En lo que respecta al ambiente de desarrollo vemos en la Figura 7 que se tiene

que hacer la liberacioacuten de las poliacuteticas la liberacioacuten de la planeacioacuten el disentildeo

loacutegico de la infraestructura que se va a implementar y la adquisicioacuten de

software y hardware estaacuten 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 construccioacuten y

liberacioacuten de las configuraciones (nivel loacutegico) se hacen las pruebas para

establecer los acuerdos de aceptacioacuten se da la aceptacioacuten total de versiones y

de modelos se arranca la planeacioacuten y finalmente las pruebas y

comunicaciones y en lo que es el ambiente real vemos que se da la

distribucioacuten e instalacioacuten 10

En la etapa del ambiente real es la que se ve de forma maacutes concreta ya que

muchas veces no tenemos idea de todo lo que pasa hasta antes de la

instalacioacuten

En el proceso de entrega del servicio es el punto en el que el usuario hace uno

del servicio y no sabe que detraacutes del servicio que estaacute 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 maacutes 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 planeacioacuten monitoreo anaacutelisis y por un sin fin de pruebas con la intencioacuten

de que en caso de que algo no funcione se deacute en la fase de pruebas

controladas y no en la fase de pruebas en ambiente real donde el mayor

afectado es el cliente

10

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 18

Figura 7 Proceso de manejo de entregas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 19

CAPITULO II

GESTION DE VERSIONES

21 Introduccioacuten y Objetivos

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten 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 implementacioacuten de cualquier

cambio

La Gestioacuten de Cambios es la encargada de aprobar y supervisar todo el

proceso pero es tarea especiacutefica de la Gestioacuten de Versiones el disentildear poner a

prueba e instalar en el entorno de produccioacuten los cambios preestablecidos

Todo ello requiere de una cuidadosa planificacioacuten y coordinacioacuten con el resto

de procesos asociados a la Gestioacuten de Servicios TI

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 20

Entre los principales objetivos de la Gestioacuten de Versiones se incluyen

Establecer una poliacutetica de implementacioacuten de nuevas versiones de

hardware y software

Implementar las nuevas versiones de software y hardware en el entorno

de produccioacuten tras su verificacioacuten en un entorno realista de pruebas

Garantizar que el proceso de cambio cumpla las especificaciones de la

RFC correspondiente

Asegurar en colaboracioacuten con la Gestioacuten de Cambios y

Configuraciones que todos los cambios se ven correctamente reflejados

en la CMDB

Archivar copias ideacutenticas del software en produccioacuten asiacute como de toda

su documentacioacuten asociada en la Biblioteca de Software Definitivo

(DSL)

Mantener actualizado el Depoacutesito de Hardware Definitivo (DHS)

22 Beneficios y Dificultades

Los beneficios de una correcta Gestioacuten 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 nuacutemero de incidentes por incompatibilidades con otro

software o hardware instalado

El proceso de pruebas asociado no soacutelo permite asegurar la calidad del

software y hardware a instalar sino que tambieacuten permite conocer la

opinioacuten 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 nuacutemero de copias de software ilegales

Control centralizado del software y hardware desplegado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 21

Proteccioacuten contra virus y problemas asociados a versiones de software

incontroladas

Las principales dificultades con las que topa la Gestioacuten de Versiones son

No existe una clara asignacioacuten de responsabilidades yo la organizacioacuten

TI no acepta la figura dominante de la Gestioacuten de Versiones en todo el

proceso de implementacioacuten 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 centralizacioacuten del

proceso de cambio Es habitual que existan reticencias a adoptar

sistemas estandarizados en toda la organizacioacuten sobre todo cuando

eacutesta no ha sido la poliacutetica tradicional de la misma

Se realizan cambios sin tener en cuenta a la Gestioacuten de Versiones

argumentado que estos soacutelo son responsabilidad de un determinado

grupo de trabajo o que su urgencia requeriacutea de ello

Hay resistencias a aceptar posibles planes de back-out Ciertos

entornos de produccioacuten pueden elegir ignorar lo problemas que una

nueva versioacuten puede provocar en otras aacutereas y resistirse a volver a la

uacuteltima versioacuten estable

La implementacioacuten sincronizada de versiones en entornos altamente

distribuidos

La solucioacuten a estos problemas pasa por

Un firme compromiso de la organizacioacuten con la Gestioacuten de Versiones y

sus responsables

Un adecuado plan de comunicacioacuten que informe a todos los

responsables y usuarios de la organizacioacuten TI de las ventajas de una

correcta gestioacuten de todo el proceso de cambio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 22

Una versioacuten es un grupo de CIs de nueva creacioacuten o modificados que han sido

validados para su instalacioacuten en el entorno de produccioacuten Las especificaciones

funcionales y teacutecnicas de una versioacuten estaacuten determinadas en la RFC

correspondiente

23 Clasificacioacuten de las Versiones

Las versiones pueden clasificarse seguacuten 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 caracteriacutesticas teacutecnicas etc

Versiones menores que suelen implicar la correccioacuten 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 raacutepida

un error conocido

Como pueden llegar a existir muacuteltiples versiones es conveniente definir una

referencia o coacutedigo que los identifique uniacutevocamente El sistema

universalmente aceptado es

Versiones mayores 10 20 etc

Versiones menores 11 12 13 etc

Versiones de emergencia 111 112 etc

Aunque en algunos casos esta clasificacioacuten se refina auacuten maacutes (vea por

ejemplo en la ayuda la versioacuten de su navegador)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 23

En su ciclo de vida una versioacuten puede encontrase en diversos estados

desarrollo pruebas produccioacuten y archivado11

En la Figura 8 nos ilustra graacuteficamente la evolucioacuten temporal de una versioacuten

Figura 8 Evolucioacuten temporal de una versioacuten

El despliegue de nuevas versiones puede realizarse de diferentes maneras y

es responsabilidad de la Gestioacuten de Cambios el determinar la forma maacutes

conveniente de hacerlo Entre las opciones maacutes habituales cabe contar

Versioacuten delta soacutelo se testean e instalan los elementos modificados

Esta opcioacuten tiene como ventaja su mayor simplicidad pero conlleva el

peligro de que puedan aparecer problemas e incompatibilidades en el

entorno de produccioacuten

Versioacuten completa Se distribuyen todos los elementos afectados ya

hayan sido modificados o no Aunque esta opcioacuten es obviamente maacutes

trabajosa es maacutes improbable que se generen incidentes tras la

instalacioacuten si se han realizado las pruebas pertinentes

11

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 24

Paquete de Versiones La Gestioacuten 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 opcioacuten es obligada por incompatibilidades entre una nueva

versioacuten con software o hardware previamente instalado Pensemos por

ejemplo en la migracioacuten a un nuevo sistema operativo que requiere

hardware maacutes avanzado yo nuevos versiones de los programas

ofimaacuteticos

24 Visioacuten General

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI12

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten de Versiones se resumen

sucintamente en la siguiente Figura 9

12

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 25

Figura 9 Visioacuten General de la Gestioacuten de Versiones

25 Planificacioacuten

Es crucial establecer un marco general para el lanzamiento de nuevas

versiones que fije una metodologiacutea 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

especiacuteficos que tomen en cuenta las peculiaridades de cada caso

A la hora de planificar correctamente el lanzamiento de una nueva versioacuten se

deben de tomar en cuenta los siguientes factores

Coacutemo puede afectar la nueva versioacuten a otras aacutereas del entramado TI

Queacute CIs se veraacuten directa o indirectamente implicados durante y tras el

lanzamiento de la nueva versioacuten

Coacutemo ha de construirse el entorno de pruebas para que eacuteste sea fiel

reflejo del entorno de produccioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 26

Queacute planes de back-out son necesarios

Coacutemo y cuaacutendo se deben implementar los planes de back-out para

minimizar el posible impacto negativo sobre el servicio y la integridad del

sistema TI

Cuaacuteles son los recursos humanos y teacutecnicos necesarios para llevar a

cabo la implementacioacuten de la nueva versioacuten con garantiacuteas de eacutexito

Quieacutenes seraacuten los responsables directos en las diferentes etapas del

proceso

Queacute planes de comunicacioacuten yo formacioacuten deben desarrollarse para

que los usuarios esteacuten puntualmente informados y puedan percibir la

nueva versioacuten como una mejora

Queacute tipo de despliegue es el maacutes adecuado completo delta

sincronizado en todas los emplazamientos gradual

Cuaacutel es la vida media uacutetil esperada de la nueva versioacuten

Queacute impacto puede tener el proceso de lanzamiento de la nueva versioacuten

en la calidad del servicio

Si es posible establecer meacutetricas precisas que determinen el grado de

eacutexito del lanzamiento de la nueva versioacuten

26 Desarrollo

La Gestioacuten de Versiones es la encargada del disentildeo y construccioacuten de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes

A veces el desarrollo se realizara en la casa y muchas otras requeriraacute la

participacioacuten de proveedores externos En este segundo caso la tarea de la

Gestioacuten de Versiones seraacute la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC Asimismo la Gestioacuten de Versiones seraacute la responsable de todo el

proceso de configuracioacuten necesario

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

Parte integrante del desarrollo lo componen los planes de back-out asociados

Estos tendraacuten que tomar en cuenta la disponibilidad acordada con los clientes

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

Es importante que las pruebas incluyan los planes de back-out para

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

Que meacutetricas determinan la puesta en marcha de los planes de back-out

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

informada por el Service Desk de los comentarios quejas incidentes etc que

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

recibidas y que se tomen las medidas correctivas necesarias para minimizar el

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

Es frecuente y a su vez un grave error que cuando se aborden cuestiones de

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

Es inuacutetil disponer de un sofisticado servicio TI si los usuarios debido a una

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

remotos mediante moacutedulos de e-learning sobre el funcionamiento de la

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 9: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 9

Hay mucha confusioacuten sobre ITIL procedente de todo tipo de malentendidos

sobre su naturaleza ITIL como afirma la OGC es un conjunto de buenas

praacutecticas La OGC no afirma que dichas mejoras praacutecticas describan procesos

puros ni tampoco que ITIL sea un marco disentildeado como un modelo coherente

Eso es lo que la mayoriacutea de sus usuarios hacen de ella probablemente porque

tienen una gran necesidad de dicho modelo 3

El columnista CIO Magazine Dean Meyer tambieacuten ha expuesto algunos puntos

de vista cautelosos sobre ITIL incluyendo cinco trampas tiacutepicas tales como

laquoconvertirse en esclavo de definiciones desactualizadasraquo y laquodejar que ITIL se

convierta en religioacutenraquo Como Meyer sentildeala ITIL laquono describe el abanico

completo de procesos necesarios para ser liacutederes Se centra en [] gestionar

servicios actualesraquo4

La calidad de los voluacutemenes de la biblioteca se considera desigual Por

ejemplo Van Herwaarden y Grift sentildealan que laquola consistencia que

caracterizaba los procesos de soporte al servicio [] se pierde en gran medida

en los libros de entrega de servicioraquo5

17 Forma de uso de ITIL en Managed Services

ITIL postula que el servicio de soporte la administracioacuten y la operacioacuten se

realiza a traveacutes 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 Gestioacuten de Servicios de TI)

4 CIO Magazine Dean Meyer

5 Van Herwaarden y Grift

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 10

171 PROCESO DE MANEJO DE INCIDENTES

Su objetivo primordial es restablecer el servicio lo maacutes raacutepido posible para

evitar que el cliente se vea afectado esto se hace con la finalidad de que se

minimicen los efectos de la operacioacuten Se dice que el proveedor de debe de

encargar de que el cliente no debe percibir todas aquellas pequentildeas 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 baacutesicos que son propiedad monitoreo manejo de secuencias y

comunicacioacuten

En el proceso de manejo de incidentes vemos en la Figura 3 que se da como

primera etapa la deteccioacuten del incidente (es cuando el sistema presenta alguna

anomaliacutea 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 clasificacioacuten 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 seguacuten el manual de procedimientos para poder llegar a la

solucioacuten de una forma viable y eficiente) una vez que ya que se la dio una

solucioacuten al incidente por medio del manual de procedimientos se recurre a la

documentacioacuten y contabilizacioacuten del incidente para ver queacute tanta incidencia

tiene este caso finalmente se hace una evaluacioacuten para ver si efectivamente

se resolvioacute el incidente de forma satisfactoria y en supuesto de ser afirmativa

se cierra el incidente y el otro supuesto seria que de la solucioacuten que se planteo

no es lo suficientemente eficiente o acertada para que resuelva el problema y

se recurre a hacer una investigacioacuten y un diagnostico de la situacioacuten para ver

coacutemo es que se puede atacar el problema de frente y resolverlo una vez que

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 11

se tiene todo un contexto analizado se recurre a la ejecucioacuten de la propuesta

de solucioacuten del incidente y se hace un estudio para ver si el incidente es

recuperable o si es caso perdido (la mayoriacutea de los casos son recuperables

peo cuando el nivel de dantildeo es muy fuerte se da el caso de que se deacute por

perdido) y finamente se cierra el incidente y esta solucioacuten se documenta en

una base de datos a la que se le llama base del conocimiento o Knowledge

Data Base (aquiacute 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 maacutes faacutecil raacutepida y eficiente su resolucioacuten6

Figura 3 Proceso de manejo de incidentes

172 PROCESO DE MANEJO DE PROBLEMAS

El Objetivo de este proceso es prevenir y reducir al maacuteximo los incidentes y

esto nos lleva a una reduccioacuten en el nivel de incidencia Por otro lado nos

6 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtml

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 12

ayuda a proporcionar soluciones raacutepidas 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 daacutendole 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 estaacute relacionada con lo que es el control del problema y la segunda

es con el control del error7

En lo que respecta a la fase de control del problema primero se tiene que

identificar el problema en base a alguna sintomatologiacutea ya que tenemos este

antecedente pasamos a la clasificacioacuten 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

estaacuten en el manual de procedimientos y en caso de no ser conocido se tendriacutea

que hacer una fase de investigacioacuten para ver queacute es lo que genera el problema

y maacutes tarde hacer un diagnostico ya que tenemos un diagnoacutestico 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 solucioacuten

y finalmente se va a hacer una evaluacioacuten para ver si se resolvioacute el problema

de raiacutez En caso de que si se funcione esta solucioacuten se pasa a la

documentacioacuten

Con lo que respecta a la segunda fase del modelo el control del error se hace

por medio de una identificacioacuten 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 clasificacioacuten y se recurre a una evaluacioacuten de que tanto dantildeo genero

o puede llegar a generar el error esto con la finalidad de cuantificar los

desperfectos que podriacutea llegar a causar en caso de que el error prevalezca y

no se solucione posteriormente se hace la resolucioacuten o correccioacuten del error

7 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 13

(este puede deberse a varios aspectos configuraciones falta de seguridad

inconsistencia de datos etc) y este modelo tiene una fase muy difiacutecil que es

determinar que problemas estaacuten 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 pasariacutea si

cambio algunos de los datos en la configuracioacuten del sistema se tendriacutea que

afectar el sistema de manera uniforme para que siga en equilibrio y no esteacute

cambiado en algunas partes y en otras que se quede como estaba antes

Figura 4 Proceso de manejo de problemas

173 PROCESO DE MANEJO DE CONFIGURACIONES

Su objetivo es proveer con informacioacuten real y actualizada de lo que se tiene

configurado e instalado en cada sistema del cliente

Este proceso es de los maacutes complejos como muestra la Figura 5 ya que se

mueve bajo cuatro veacutertices que son administracioacuten de cambios administracioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 14

de liberaciones administracioacuten de configuraciones y la administracioacuten de

procesos diversos8

El nivel de complejidad de este modelo es alto ya que influyen muchas

variables y muchas de ellas son dinaacutemicas entonces al cambiar una o varias

de ellas se afecta el sistema en general lo que hace que sea muy difiacutecil de

manipular Aunque es lo maacutes parecido a la realidad porque nuestro entorno es

dinaacutemico y las decisiones de unos afectan a otros Por ejemplo en lo que

respecta a la administracioacuten de cambios vemos que se relaciona directamente

con la administracioacuten de incidentes y de problemas lo que conlleva una

planeacioacuten identificacioacuten control seguimiento del status verificacioacuten y

auditoria de configuraciones lo que hace que haya muchas variables

En otro ejemplo la implementacioacuten de cambios implica que se tiene que hacer

la liberacioacuten y distribucioacuten de nuevas versiones esto de da por una fase de

planeacioacuten identificacioacuten control revisioacuten del status verificacioacuten y auditoria y

puede depender de la administracioacuten de las capacidades ya que si no se

cuenta con el software o con el hardware esta fase no se podriacutea llevar a cabo y

asiacute se hariacutea con todos los niveles hasta llegar al cierre del control de cambios

8 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 15

Figura 5 Proceso de manejo de configuraciones

174 PROCESO DE CONTROL DE CAMBIOS

El objetivo de este proceso es reducir los riesgos tanto teacutecnicos econoacutemicos y

de tiempo al momento de la realizacioacuten de los cambios

La Figura 6 al parecer es muy faacutecil 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 objetivos9

Primero vemos que tenemos un registro y clasificacioacuten del cambio que se tiene

que hacer se pasa a la fase de monitoreo y planeacioacuten si el rendimiento es

9 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 16

satisfactorio se da la aprobacioacuten del cambio y en caso de que el rendimiento

sea malo se pasa a la fase de reingenieriacutea 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 estaacute

probado se da la autorizacioacuten e implementacioacuten ya implementado se ve que no

se hayan tenido desviaciones y se ajusta a las necesidades actuales que

tambieacuten se le considera como revisioacuten post-implementacioacuten

Figura 6 Proceso de control de cambios

175 PROCESO DE MANEJO DE ENTREGAS

Su objetivo es planear y controlar exitosamente la instalacioacuten 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 transicioacuten que se da de acuerdo

a los ambientes por los que se va dando la evolucioacuten del proyecto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 17

En lo que respecta al ambiente de desarrollo vemos en la Figura 7 que se tiene

que hacer la liberacioacuten de las poliacuteticas la liberacioacuten de la planeacioacuten el disentildeo

loacutegico de la infraestructura que se va a implementar y la adquisicioacuten de

software y hardware estaacuten 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 construccioacuten y

liberacioacuten de las configuraciones (nivel loacutegico) se hacen las pruebas para

establecer los acuerdos de aceptacioacuten se da la aceptacioacuten total de versiones y

de modelos se arranca la planeacioacuten y finalmente las pruebas y

comunicaciones y en lo que es el ambiente real vemos que se da la

distribucioacuten e instalacioacuten 10

En la etapa del ambiente real es la que se ve de forma maacutes concreta ya que

muchas veces no tenemos idea de todo lo que pasa hasta antes de la

instalacioacuten

En el proceso de entrega del servicio es el punto en el que el usuario hace uno

del servicio y no sabe que detraacutes del servicio que estaacute 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 maacutes 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 planeacioacuten monitoreo anaacutelisis y por un sin fin de pruebas con la intencioacuten

de que en caso de que algo no funcione se deacute en la fase de pruebas

controladas y no en la fase de pruebas en ambiente real donde el mayor

afectado es el cliente

10

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 18

Figura 7 Proceso de manejo de entregas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 19

CAPITULO II

GESTION DE VERSIONES

21 Introduccioacuten y Objetivos

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten 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 implementacioacuten de cualquier

cambio

La Gestioacuten de Cambios es la encargada de aprobar y supervisar todo el

proceso pero es tarea especiacutefica de la Gestioacuten de Versiones el disentildear poner a

prueba e instalar en el entorno de produccioacuten los cambios preestablecidos

Todo ello requiere de una cuidadosa planificacioacuten y coordinacioacuten con el resto

de procesos asociados a la Gestioacuten de Servicios TI

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 20

Entre los principales objetivos de la Gestioacuten de Versiones se incluyen

Establecer una poliacutetica de implementacioacuten de nuevas versiones de

hardware y software

Implementar las nuevas versiones de software y hardware en el entorno

de produccioacuten tras su verificacioacuten en un entorno realista de pruebas

Garantizar que el proceso de cambio cumpla las especificaciones de la

RFC correspondiente

Asegurar en colaboracioacuten con la Gestioacuten de Cambios y

Configuraciones que todos los cambios se ven correctamente reflejados

en la CMDB

Archivar copias ideacutenticas del software en produccioacuten asiacute como de toda

su documentacioacuten asociada en la Biblioteca de Software Definitivo

(DSL)

Mantener actualizado el Depoacutesito de Hardware Definitivo (DHS)

22 Beneficios y Dificultades

Los beneficios de una correcta Gestioacuten 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 nuacutemero de incidentes por incompatibilidades con otro

software o hardware instalado

El proceso de pruebas asociado no soacutelo permite asegurar la calidad del

software y hardware a instalar sino que tambieacuten permite conocer la

opinioacuten 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 nuacutemero de copias de software ilegales

Control centralizado del software y hardware desplegado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 21

Proteccioacuten contra virus y problemas asociados a versiones de software

incontroladas

Las principales dificultades con las que topa la Gestioacuten de Versiones son

No existe una clara asignacioacuten de responsabilidades yo la organizacioacuten

TI no acepta la figura dominante de la Gestioacuten de Versiones en todo el

proceso de implementacioacuten 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 centralizacioacuten del

proceso de cambio Es habitual que existan reticencias a adoptar

sistemas estandarizados en toda la organizacioacuten sobre todo cuando

eacutesta no ha sido la poliacutetica tradicional de la misma

Se realizan cambios sin tener en cuenta a la Gestioacuten de Versiones

argumentado que estos soacutelo son responsabilidad de un determinado

grupo de trabajo o que su urgencia requeriacutea de ello

Hay resistencias a aceptar posibles planes de back-out Ciertos

entornos de produccioacuten pueden elegir ignorar lo problemas que una

nueva versioacuten puede provocar en otras aacutereas y resistirse a volver a la

uacuteltima versioacuten estable

La implementacioacuten sincronizada de versiones en entornos altamente

distribuidos

La solucioacuten a estos problemas pasa por

Un firme compromiso de la organizacioacuten con la Gestioacuten de Versiones y

sus responsables

Un adecuado plan de comunicacioacuten que informe a todos los

responsables y usuarios de la organizacioacuten TI de las ventajas de una

correcta gestioacuten de todo el proceso de cambio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 22

Una versioacuten es un grupo de CIs de nueva creacioacuten o modificados que han sido

validados para su instalacioacuten en el entorno de produccioacuten Las especificaciones

funcionales y teacutecnicas de una versioacuten estaacuten determinadas en la RFC

correspondiente

23 Clasificacioacuten de las Versiones

Las versiones pueden clasificarse seguacuten 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 caracteriacutesticas teacutecnicas etc

Versiones menores que suelen implicar la correccioacuten 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 raacutepida

un error conocido

Como pueden llegar a existir muacuteltiples versiones es conveniente definir una

referencia o coacutedigo que los identifique uniacutevocamente El sistema

universalmente aceptado es

Versiones mayores 10 20 etc

Versiones menores 11 12 13 etc

Versiones de emergencia 111 112 etc

Aunque en algunos casos esta clasificacioacuten se refina auacuten maacutes (vea por

ejemplo en la ayuda la versioacuten de su navegador)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 23

En su ciclo de vida una versioacuten puede encontrase en diversos estados

desarrollo pruebas produccioacuten y archivado11

En la Figura 8 nos ilustra graacuteficamente la evolucioacuten temporal de una versioacuten

Figura 8 Evolucioacuten temporal de una versioacuten

El despliegue de nuevas versiones puede realizarse de diferentes maneras y

es responsabilidad de la Gestioacuten de Cambios el determinar la forma maacutes

conveniente de hacerlo Entre las opciones maacutes habituales cabe contar

Versioacuten delta soacutelo se testean e instalan los elementos modificados

Esta opcioacuten tiene como ventaja su mayor simplicidad pero conlleva el

peligro de que puedan aparecer problemas e incompatibilidades en el

entorno de produccioacuten

Versioacuten completa Se distribuyen todos los elementos afectados ya

hayan sido modificados o no Aunque esta opcioacuten es obviamente maacutes

trabajosa es maacutes improbable que se generen incidentes tras la

instalacioacuten si se han realizado las pruebas pertinentes

11

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 24

Paquete de Versiones La Gestioacuten 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 opcioacuten es obligada por incompatibilidades entre una nueva

versioacuten con software o hardware previamente instalado Pensemos por

ejemplo en la migracioacuten a un nuevo sistema operativo que requiere

hardware maacutes avanzado yo nuevos versiones de los programas

ofimaacuteticos

24 Visioacuten General

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI12

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten de Versiones se resumen

sucintamente en la siguiente Figura 9

12

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 25

Figura 9 Visioacuten General de la Gestioacuten de Versiones

25 Planificacioacuten

Es crucial establecer un marco general para el lanzamiento de nuevas

versiones que fije una metodologiacutea 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

especiacuteficos que tomen en cuenta las peculiaridades de cada caso

A la hora de planificar correctamente el lanzamiento de una nueva versioacuten se

deben de tomar en cuenta los siguientes factores

Coacutemo puede afectar la nueva versioacuten a otras aacutereas del entramado TI

Queacute CIs se veraacuten directa o indirectamente implicados durante y tras el

lanzamiento de la nueva versioacuten

Coacutemo ha de construirse el entorno de pruebas para que eacuteste sea fiel

reflejo del entorno de produccioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 26

Queacute planes de back-out son necesarios

Coacutemo y cuaacutendo se deben implementar los planes de back-out para

minimizar el posible impacto negativo sobre el servicio y la integridad del

sistema TI

Cuaacuteles son los recursos humanos y teacutecnicos necesarios para llevar a

cabo la implementacioacuten de la nueva versioacuten con garantiacuteas de eacutexito

Quieacutenes seraacuten los responsables directos en las diferentes etapas del

proceso

Queacute planes de comunicacioacuten yo formacioacuten deben desarrollarse para

que los usuarios esteacuten puntualmente informados y puedan percibir la

nueva versioacuten como una mejora

Queacute tipo de despliegue es el maacutes adecuado completo delta

sincronizado en todas los emplazamientos gradual

Cuaacutel es la vida media uacutetil esperada de la nueva versioacuten

Queacute impacto puede tener el proceso de lanzamiento de la nueva versioacuten

en la calidad del servicio

Si es posible establecer meacutetricas precisas que determinen el grado de

eacutexito del lanzamiento de la nueva versioacuten

26 Desarrollo

La Gestioacuten de Versiones es la encargada del disentildeo y construccioacuten de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes

A veces el desarrollo se realizara en la casa y muchas otras requeriraacute la

participacioacuten de proveedores externos En este segundo caso la tarea de la

Gestioacuten de Versiones seraacute la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC Asimismo la Gestioacuten de Versiones seraacute la responsable de todo el

proceso de configuracioacuten necesario

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

Parte integrante del desarrollo lo componen los planes de back-out asociados

Estos tendraacuten que tomar en cuenta la disponibilidad acordada con los clientes

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

Es importante que las pruebas incluyan los planes de back-out para

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

Que meacutetricas determinan la puesta en marcha de los planes de back-out

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

informada por el Service Desk de los comentarios quejas incidentes etc que

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

recibidas y que se tomen las medidas correctivas necesarias para minimizar el

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

Es frecuente y a su vez un grave error que cuando se aborden cuestiones de

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

Es inuacutetil disponer de un sofisticado servicio TI si los usuarios debido a una

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

remotos mediante moacutedulos de e-learning sobre el funcionamiento de la

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 10: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 10

171 PROCESO DE MANEJO DE INCIDENTES

Su objetivo primordial es restablecer el servicio lo maacutes raacutepido posible para

evitar que el cliente se vea afectado esto se hace con la finalidad de que se

minimicen los efectos de la operacioacuten Se dice que el proveedor de debe de

encargar de que el cliente no debe percibir todas aquellas pequentildeas 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 baacutesicos que son propiedad monitoreo manejo de secuencias y

comunicacioacuten

En el proceso de manejo de incidentes vemos en la Figura 3 que se da como

primera etapa la deteccioacuten del incidente (es cuando el sistema presenta alguna

anomaliacutea 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 clasificacioacuten 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 seguacuten el manual de procedimientos para poder llegar a la

solucioacuten de una forma viable y eficiente) una vez que ya que se la dio una

solucioacuten al incidente por medio del manual de procedimientos se recurre a la

documentacioacuten y contabilizacioacuten del incidente para ver queacute tanta incidencia

tiene este caso finalmente se hace una evaluacioacuten para ver si efectivamente

se resolvioacute el incidente de forma satisfactoria y en supuesto de ser afirmativa

se cierra el incidente y el otro supuesto seria que de la solucioacuten que se planteo

no es lo suficientemente eficiente o acertada para que resuelva el problema y

se recurre a hacer una investigacioacuten y un diagnostico de la situacioacuten para ver

coacutemo es que se puede atacar el problema de frente y resolverlo una vez que

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 11

se tiene todo un contexto analizado se recurre a la ejecucioacuten de la propuesta

de solucioacuten del incidente y se hace un estudio para ver si el incidente es

recuperable o si es caso perdido (la mayoriacutea de los casos son recuperables

peo cuando el nivel de dantildeo es muy fuerte se da el caso de que se deacute por

perdido) y finamente se cierra el incidente y esta solucioacuten se documenta en

una base de datos a la que se le llama base del conocimiento o Knowledge

Data Base (aquiacute 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 maacutes faacutecil raacutepida y eficiente su resolucioacuten6

Figura 3 Proceso de manejo de incidentes

172 PROCESO DE MANEJO DE PROBLEMAS

El Objetivo de este proceso es prevenir y reducir al maacuteximo los incidentes y

esto nos lleva a una reduccioacuten en el nivel de incidencia Por otro lado nos

6 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtml

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 12

ayuda a proporcionar soluciones raacutepidas 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 daacutendole 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 estaacute relacionada con lo que es el control del problema y la segunda

es con el control del error7

En lo que respecta a la fase de control del problema primero se tiene que

identificar el problema en base a alguna sintomatologiacutea ya que tenemos este

antecedente pasamos a la clasificacioacuten 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

estaacuten en el manual de procedimientos y en caso de no ser conocido se tendriacutea

que hacer una fase de investigacioacuten para ver queacute es lo que genera el problema

y maacutes tarde hacer un diagnostico ya que tenemos un diagnoacutestico 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 solucioacuten

y finalmente se va a hacer una evaluacioacuten para ver si se resolvioacute el problema

de raiacutez En caso de que si se funcione esta solucioacuten se pasa a la

documentacioacuten

Con lo que respecta a la segunda fase del modelo el control del error se hace

por medio de una identificacioacuten 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 clasificacioacuten y se recurre a una evaluacioacuten de que tanto dantildeo genero

o puede llegar a generar el error esto con la finalidad de cuantificar los

desperfectos que podriacutea llegar a causar en caso de que el error prevalezca y

no se solucione posteriormente se hace la resolucioacuten o correccioacuten del error

7 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 13

(este puede deberse a varios aspectos configuraciones falta de seguridad

inconsistencia de datos etc) y este modelo tiene una fase muy difiacutecil que es

determinar que problemas estaacuten 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 pasariacutea si

cambio algunos de los datos en la configuracioacuten del sistema se tendriacutea que

afectar el sistema de manera uniforme para que siga en equilibrio y no esteacute

cambiado en algunas partes y en otras que se quede como estaba antes

Figura 4 Proceso de manejo de problemas

173 PROCESO DE MANEJO DE CONFIGURACIONES

Su objetivo es proveer con informacioacuten real y actualizada de lo que se tiene

configurado e instalado en cada sistema del cliente

Este proceso es de los maacutes complejos como muestra la Figura 5 ya que se

mueve bajo cuatro veacutertices que son administracioacuten de cambios administracioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 14

de liberaciones administracioacuten de configuraciones y la administracioacuten de

procesos diversos8

El nivel de complejidad de este modelo es alto ya que influyen muchas

variables y muchas de ellas son dinaacutemicas entonces al cambiar una o varias

de ellas se afecta el sistema en general lo que hace que sea muy difiacutecil de

manipular Aunque es lo maacutes parecido a la realidad porque nuestro entorno es

dinaacutemico y las decisiones de unos afectan a otros Por ejemplo en lo que

respecta a la administracioacuten de cambios vemos que se relaciona directamente

con la administracioacuten de incidentes y de problemas lo que conlleva una

planeacioacuten identificacioacuten control seguimiento del status verificacioacuten y

auditoria de configuraciones lo que hace que haya muchas variables

En otro ejemplo la implementacioacuten de cambios implica que se tiene que hacer

la liberacioacuten y distribucioacuten de nuevas versiones esto de da por una fase de

planeacioacuten identificacioacuten control revisioacuten del status verificacioacuten y auditoria y

puede depender de la administracioacuten de las capacidades ya que si no se

cuenta con el software o con el hardware esta fase no se podriacutea llevar a cabo y

asiacute se hariacutea con todos los niveles hasta llegar al cierre del control de cambios

8 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 15

Figura 5 Proceso de manejo de configuraciones

174 PROCESO DE CONTROL DE CAMBIOS

El objetivo de este proceso es reducir los riesgos tanto teacutecnicos econoacutemicos y

de tiempo al momento de la realizacioacuten de los cambios

La Figura 6 al parecer es muy faacutecil 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 objetivos9

Primero vemos que tenemos un registro y clasificacioacuten del cambio que se tiene

que hacer se pasa a la fase de monitoreo y planeacioacuten si el rendimiento es

9 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 16

satisfactorio se da la aprobacioacuten del cambio y en caso de que el rendimiento

sea malo se pasa a la fase de reingenieriacutea 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 estaacute

probado se da la autorizacioacuten e implementacioacuten ya implementado se ve que no

se hayan tenido desviaciones y se ajusta a las necesidades actuales que

tambieacuten se le considera como revisioacuten post-implementacioacuten

Figura 6 Proceso de control de cambios

175 PROCESO DE MANEJO DE ENTREGAS

Su objetivo es planear y controlar exitosamente la instalacioacuten 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 transicioacuten que se da de acuerdo

a los ambientes por los que se va dando la evolucioacuten del proyecto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 17

En lo que respecta al ambiente de desarrollo vemos en la Figura 7 que se tiene

que hacer la liberacioacuten de las poliacuteticas la liberacioacuten de la planeacioacuten el disentildeo

loacutegico de la infraestructura que se va a implementar y la adquisicioacuten de

software y hardware estaacuten 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 construccioacuten y

liberacioacuten de las configuraciones (nivel loacutegico) se hacen las pruebas para

establecer los acuerdos de aceptacioacuten se da la aceptacioacuten total de versiones y

de modelos se arranca la planeacioacuten y finalmente las pruebas y

comunicaciones y en lo que es el ambiente real vemos que se da la

distribucioacuten e instalacioacuten 10

En la etapa del ambiente real es la que se ve de forma maacutes concreta ya que

muchas veces no tenemos idea de todo lo que pasa hasta antes de la

instalacioacuten

En el proceso de entrega del servicio es el punto en el que el usuario hace uno

del servicio y no sabe que detraacutes del servicio que estaacute 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 maacutes 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 planeacioacuten monitoreo anaacutelisis y por un sin fin de pruebas con la intencioacuten

de que en caso de que algo no funcione se deacute en la fase de pruebas

controladas y no en la fase de pruebas en ambiente real donde el mayor

afectado es el cliente

10

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 18

Figura 7 Proceso de manejo de entregas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 19

CAPITULO II

GESTION DE VERSIONES

21 Introduccioacuten y Objetivos

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten 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 implementacioacuten de cualquier

cambio

La Gestioacuten de Cambios es la encargada de aprobar y supervisar todo el

proceso pero es tarea especiacutefica de la Gestioacuten de Versiones el disentildear poner a

prueba e instalar en el entorno de produccioacuten los cambios preestablecidos

Todo ello requiere de una cuidadosa planificacioacuten y coordinacioacuten con el resto

de procesos asociados a la Gestioacuten de Servicios TI

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 20

Entre los principales objetivos de la Gestioacuten de Versiones se incluyen

Establecer una poliacutetica de implementacioacuten de nuevas versiones de

hardware y software

Implementar las nuevas versiones de software y hardware en el entorno

de produccioacuten tras su verificacioacuten en un entorno realista de pruebas

Garantizar que el proceso de cambio cumpla las especificaciones de la

RFC correspondiente

Asegurar en colaboracioacuten con la Gestioacuten de Cambios y

Configuraciones que todos los cambios se ven correctamente reflejados

en la CMDB

Archivar copias ideacutenticas del software en produccioacuten asiacute como de toda

su documentacioacuten asociada en la Biblioteca de Software Definitivo

(DSL)

Mantener actualizado el Depoacutesito de Hardware Definitivo (DHS)

22 Beneficios y Dificultades

Los beneficios de una correcta Gestioacuten 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 nuacutemero de incidentes por incompatibilidades con otro

software o hardware instalado

El proceso de pruebas asociado no soacutelo permite asegurar la calidad del

software y hardware a instalar sino que tambieacuten permite conocer la

opinioacuten 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 nuacutemero de copias de software ilegales

Control centralizado del software y hardware desplegado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 21

Proteccioacuten contra virus y problemas asociados a versiones de software

incontroladas

Las principales dificultades con las que topa la Gestioacuten de Versiones son

No existe una clara asignacioacuten de responsabilidades yo la organizacioacuten

TI no acepta la figura dominante de la Gestioacuten de Versiones en todo el

proceso de implementacioacuten 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 centralizacioacuten del

proceso de cambio Es habitual que existan reticencias a adoptar

sistemas estandarizados en toda la organizacioacuten sobre todo cuando

eacutesta no ha sido la poliacutetica tradicional de la misma

Se realizan cambios sin tener en cuenta a la Gestioacuten de Versiones

argumentado que estos soacutelo son responsabilidad de un determinado

grupo de trabajo o que su urgencia requeriacutea de ello

Hay resistencias a aceptar posibles planes de back-out Ciertos

entornos de produccioacuten pueden elegir ignorar lo problemas que una

nueva versioacuten puede provocar en otras aacutereas y resistirse a volver a la

uacuteltima versioacuten estable

La implementacioacuten sincronizada de versiones en entornos altamente

distribuidos

La solucioacuten a estos problemas pasa por

Un firme compromiso de la organizacioacuten con la Gestioacuten de Versiones y

sus responsables

Un adecuado plan de comunicacioacuten que informe a todos los

responsables y usuarios de la organizacioacuten TI de las ventajas de una

correcta gestioacuten de todo el proceso de cambio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 22

Una versioacuten es un grupo de CIs de nueva creacioacuten o modificados que han sido

validados para su instalacioacuten en el entorno de produccioacuten Las especificaciones

funcionales y teacutecnicas de una versioacuten estaacuten determinadas en la RFC

correspondiente

23 Clasificacioacuten de las Versiones

Las versiones pueden clasificarse seguacuten 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 caracteriacutesticas teacutecnicas etc

Versiones menores que suelen implicar la correccioacuten 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 raacutepida

un error conocido

Como pueden llegar a existir muacuteltiples versiones es conveniente definir una

referencia o coacutedigo que los identifique uniacutevocamente El sistema

universalmente aceptado es

Versiones mayores 10 20 etc

Versiones menores 11 12 13 etc

Versiones de emergencia 111 112 etc

Aunque en algunos casos esta clasificacioacuten se refina auacuten maacutes (vea por

ejemplo en la ayuda la versioacuten de su navegador)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 23

En su ciclo de vida una versioacuten puede encontrase en diversos estados

desarrollo pruebas produccioacuten y archivado11

En la Figura 8 nos ilustra graacuteficamente la evolucioacuten temporal de una versioacuten

Figura 8 Evolucioacuten temporal de una versioacuten

El despliegue de nuevas versiones puede realizarse de diferentes maneras y

es responsabilidad de la Gestioacuten de Cambios el determinar la forma maacutes

conveniente de hacerlo Entre las opciones maacutes habituales cabe contar

Versioacuten delta soacutelo se testean e instalan los elementos modificados

Esta opcioacuten tiene como ventaja su mayor simplicidad pero conlleva el

peligro de que puedan aparecer problemas e incompatibilidades en el

entorno de produccioacuten

Versioacuten completa Se distribuyen todos los elementos afectados ya

hayan sido modificados o no Aunque esta opcioacuten es obviamente maacutes

trabajosa es maacutes improbable que se generen incidentes tras la

instalacioacuten si se han realizado las pruebas pertinentes

11

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 24

Paquete de Versiones La Gestioacuten 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 opcioacuten es obligada por incompatibilidades entre una nueva

versioacuten con software o hardware previamente instalado Pensemos por

ejemplo en la migracioacuten a un nuevo sistema operativo que requiere

hardware maacutes avanzado yo nuevos versiones de los programas

ofimaacuteticos

24 Visioacuten General

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI12

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten de Versiones se resumen

sucintamente en la siguiente Figura 9

12

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 25

Figura 9 Visioacuten General de la Gestioacuten de Versiones

25 Planificacioacuten

Es crucial establecer un marco general para el lanzamiento de nuevas

versiones que fije una metodologiacutea 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

especiacuteficos que tomen en cuenta las peculiaridades de cada caso

A la hora de planificar correctamente el lanzamiento de una nueva versioacuten se

deben de tomar en cuenta los siguientes factores

Coacutemo puede afectar la nueva versioacuten a otras aacutereas del entramado TI

Queacute CIs se veraacuten directa o indirectamente implicados durante y tras el

lanzamiento de la nueva versioacuten

Coacutemo ha de construirse el entorno de pruebas para que eacuteste sea fiel

reflejo del entorno de produccioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 26

Queacute planes de back-out son necesarios

Coacutemo y cuaacutendo se deben implementar los planes de back-out para

minimizar el posible impacto negativo sobre el servicio y la integridad del

sistema TI

Cuaacuteles son los recursos humanos y teacutecnicos necesarios para llevar a

cabo la implementacioacuten de la nueva versioacuten con garantiacuteas de eacutexito

Quieacutenes seraacuten los responsables directos en las diferentes etapas del

proceso

Queacute planes de comunicacioacuten yo formacioacuten deben desarrollarse para

que los usuarios esteacuten puntualmente informados y puedan percibir la

nueva versioacuten como una mejora

Queacute tipo de despliegue es el maacutes adecuado completo delta

sincronizado en todas los emplazamientos gradual

Cuaacutel es la vida media uacutetil esperada de la nueva versioacuten

Queacute impacto puede tener el proceso de lanzamiento de la nueva versioacuten

en la calidad del servicio

Si es posible establecer meacutetricas precisas que determinen el grado de

eacutexito del lanzamiento de la nueva versioacuten

26 Desarrollo

La Gestioacuten de Versiones es la encargada del disentildeo y construccioacuten de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes

A veces el desarrollo se realizara en la casa y muchas otras requeriraacute la

participacioacuten de proveedores externos En este segundo caso la tarea de la

Gestioacuten de Versiones seraacute la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC Asimismo la Gestioacuten de Versiones seraacute la responsable de todo el

proceso de configuracioacuten necesario

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

Parte integrante del desarrollo lo componen los planes de back-out asociados

Estos tendraacuten que tomar en cuenta la disponibilidad acordada con los clientes

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

Es importante que las pruebas incluyan los planes de back-out para

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

Que meacutetricas determinan la puesta en marcha de los planes de back-out

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

informada por el Service Desk de los comentarios quejas incidentes etc que

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

recibidas y que se tomen las medidas correctivas necesarias para minimizar el

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

Es frecuente y a su vez un grave error que cuando se aborden cuestiones de

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

Es inuacutetil disponer de un sofisticado servicio TI si los usuarios debido a una

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

remotos mediante moacutedulos de e-learning sobre el funcionamiento de la

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 11: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 11

se tiene todo un contexto analizado se recurre a la ejecucioacuten de la propuesta

de solucioacuten del incidente y se hace un estudio para ver si el incidente es

recuperable o si es caso perdido (la mayoriacutea de los casos son recuperables

peo cuando el nivel de dantildeo es muy fuerte se da el caso de que se deacute por

perdido) y finamente se cierra el incidente y esta solucioacuten se documenta en

una base de datos a la que se le llama base del conocimiento o Knowledge

Data Base (aquiacute 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 maacutes faacutecil raacutepida y eficiente su resolucioacuten6

Figura 3 Proceso de manejo de incidentes

172 PROCESO DE MANEJO DE PROBLEMAS

El Objetivo de este proceso es prevenir y reducir al maacuteximo los incidentes y

esto nos lleva a una reduccioacuten en el nivel de incidencia Por otro lado nos

6 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtml

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 12

ayuda a proporcionar soluciones raacutepidas 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 daacutendole 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 estaacute relacionada con lo que es el control del problema y la segunda

es con el control del error7

En lo que respecta a la fase de control del problema primero se tiene que

identificar el problema en base a alguna sintomatologiacutea ya que tenemos este

antecedente pasamos a la clasificacioacuten 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

estaacuten en el manual de procedimientos y en caso de no ser conocido se tendriacutea

que hacer una fase de investigacioacuten para ver queacute es lo que genera el problema

y maacutes tarde hacer un diagnostico ya que tenemos un diagnoacutestico 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 solucioacuten

y finalmente se va a hacer una evaluacioacuten para ver si se resolvioacute el problema

de raiacutez En caso de que si se funcione esta solucioacuten se pasa a la

documentacioacuten

Con lo que respecta a la segunda fase del modelo el control del error se hace

por medio de una identificacioacuten 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 clasificacioacuten y se recurre a una evaluacioacuten de que tanto dantildeo genero

o puede llegar a generar el error esto con la finalidad de cuantificar los

desperfectos que podriacutea llegar a causar en caso de que el error prevalezca y

no se solucione posteriormente se hace la resolucioacuten o correccioacuten del error

7 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 13

(este puede deberse a varios aspectos configuraciones falta de seguridad

inconsistencia de datos etc) y este modelo tiene una fase muy difiacutecil que es

determinar que problemas estaacuten 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 pasariacutea si

cambio algunos de los datos en la configuracioacuten del sistema se tendriacutea que

afectar el sistema de manera uniforme para que siga en equilibrio y no esteacute

cambiado en algunas partes y en otras que se quede como estaba antes

Figura 4 Proceso de manejo de problemas

173 PROCESO DE MANEJO DE CONFIGURACIONES

Su objetivo es proveer con informacioacuten real y actualizada de lo que se tiene

configurado e instalado en cada sistema del cliente

Este proceso es de los maacutes complejos como muestra la Figura 5 ya que se

mueve bajo cuatro veacutertices que son administracioacuten de cambios administracioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 14

de liberaciones administracioacuten de configuraciones y la administracioacuten de

procesos diversos8

El nivel de complejidad de este modelo es alto ya que influyen muchas

variables y muchas de ellas son dinaacutemicas entonces al cambiar una o varias

de ellas se afecta el sistema en general lo que hace que sea muy difiacutecil de

manipular Aunque es lo maacutes parecido a la realidad porque nuestro entorno es

dinaacutemico y las decisiones de unos afectan a otros Por ejemplo en lo que

respecta a la administracioacuten de cambios vemos que se relaciona directamente

con la administracioacuten de incidentes y de problemas lo que conlleva una

planeacioacuten identificacioacuten control seguimiento del status verificacioacuten y

auditoria de configuraciones lo que hace que haya muchas variables

En otro ejemplo la implementacioacuten de cambios implica que se tiene que hacer

la liberacioacuten y distribucioacuten de nuevas versiones esto de da por una fase de

planeacioacuten identificacioacuten control revisioacuten del status verificacioacuten y auditoria y

puede depender de la administracioacuten de las capacidades ya que si no se

cuenta con el software o con el hardware esta fase no se podriacutea llevar a cabo y

asiacute se hariacutea con todos los niveles hasta llegar al cierre del control de cambios

8 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 15

Figura 5 Proceso de manejo de configuraciones

174 PROCESO DE CONTROL DE CAMBIOS

El objetivo de este proceso es reducir los riesgos tanto teacutecnicos econoacutemicos y

de tiempo al momento de la realizacioacuten de los cambios

La Figura 6 al parecer es muy faacutecil 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 objetivos9

Primero vemos que tenemos un registro y clasificacioacuten del cambio que se tiene

que hacer se pasa a la fase de monitoreo y planeacioacuten si el rendimiento es

9 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 16

satisfactorio se da la aprobacioacuten del cambio y en caso de que el rendimiento

sea malo se pasa a la fase de reingenieriacutea 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 estaacute

probado se da la autorizacioacuten e implementacioacuten ya implementado se ve que no

se hayan tenido desviaciones y se ajusta a las necesidades actuales que

tambieacuten se le considera como revisioacuten post-implementacioacuten

Figura 6 Proceso de control de cambios

175 PROCESO DE MANEJO DE ENTREGAS

Su objetivo es planear y controlar exitosamente la instalacioacuten 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 transicioacuten que se da de acuerdo

a los ambientes por los que se va dando la evolucioacuten del proyecto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 17

En lo que respecta al ambiente de desarrollo vemos en la Figura 7 que se tiene

que hacer la liberacioacuten de las poliacuteticas la liberacioacuten de la planeacioacuten el disentildeo

loacutegico de la infraestructura que se va a implementar y la adquisicioacuten de

software y hardware estaacuten 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 construccioacuten y

liberacioacuten de las configuraciones (nivel loacutegico) se hacen las pruebas para

establecer los acuerdos de aceptacioacuten se da la aceptacioacuten total de versiones y

de modelos se arranca la planeacioacuten y finalmente las pruebas y

comunicaciones y en lo que es el ambiente real vemos que se da la

distribucioacuten e instalacioacuten 10

En la etapa del ambiente real es la que se ve de forma maacutes concreta ya que

muchas veces no tenemos idea de todo lo que pasa hasta antes de la

instalacioacuten

En el proceso de entrega del servicio es el punto en el que el usuario hace uno

del servicio y no sabe que detraacutes del servicio que estaacute 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 maacutes 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 planeacioacuten monitoreo anaacutelisis y por un sin fin de pruebas con la intencioacuten

de que en caso de que algo no funcione se deacute en la fase de pruebas

controladas y no en la fase de pruebas en ambiente real donde el mayor

afectado es el cliente

10

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 18

Figura 7 Proceso de manejo de entregas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 19

CAPITULO II

GESTION DE VERSIONES

21 Introduccioacuten y Objetivos

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten 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 implementacioacuten de cualquier

cambio

La Gestioacuten de Cambios es la encargada de aprobar y supervisar todo el

proceso pero es tarea especiacutefica de la Gestioacuten de Versiones el disentildear poner a

prueba e instalar en el entorno de produccioacuten los cambios preestablecidos

Todo ello requiere de una cuidadosa planificacioacuten y coordinacioacuten con el resto

de procesos asociados a la Gestioacuten de Servicios TI

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 20

Entre los principales objetivos de la Gestioacuten de Versiones se incluyen

Establecer una poliacutetica de implementacioacuten de nuevas versiones de

hardware y software

Implementar las nuevas versiones de software y hardware en el entorno

de produccioacuten tras su verificacioacuten en un entorno realista de pruebas

Garantizar que el proceso de cambio cumpla las especificaciones de la

RFC correspondiente

Asegurar en colaboracioacuten con la Gestioacuten de Cambios y

Configuraciones que todos los cambios se ven correctamente reflejados

en la CMDB

Archivar copias ideacutenticas del software en produccioacuten asiacute como de toda

su documentacioacuten asociada en la Biblioteca de Software Definitivo

(DSL)

Mantener actualizado el Depoacutesito de Hardware Definitivo (DHS)

22 Beneficios y Dificultades

Los beneficios de una correcta Gestioacuten 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 nuacutemero de incidentes por incompatibilidades con otro

software o hardware instalado

El proceso de pruebas asociado no soacutelo permite asegurar la calidad del

software y hardware a instalar sino que tambieacuten permite conocer la

opinioacuten 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 nuacutemero de copias de software ilegales

Control centralizado del software y hardware desplegado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 21

Proteccioacuten contra virus y problemas asociados a versiones de software

incontroladas

Las principales dificultades con las que topa la Gestioacuten de Versiones son

No existe una clara asignacioacuten de responsabilidades yo la organizacioacuten

TI no acepta la figura dominante de la Gestioacuten de Versiones en todo el

proceso de implementacioacuten 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 centralizacioacuten del

proceso de cambio Es habitual que existan reticencias a adoptar

sistemas estandarizados en toda la organizacioacuten sobre todo cuando

eacutesta no ha sido la poliacutetica tradicional de la misma

Se realizan cambios sin tener en cuenta a la Gestioacuten de Versiones

argumentado que estos soacutelo son responsabilidad de un determinado

grupo de trabajo o que su urgencia requeriacutea de ello

Hay resistencias a aceptar posibles planes de back-out Ciertos

entornos de produccioacuten pueden elegir ignorar lo problemas que una

nueva versioacuten puede provocar en otras aacutereas y resistirse a volver a la

uacuteltima versioacuten estable

La implementacioacuten sincronizada de versiones en entornos altamente

distribuidos

La solucioacuten a estos problemas pasa por

Un firme compromiso de la organizacioacuten con la Gestioacuten de Versiones y

sus responsables

Un adecuado plan de comunicacioacuten que informe a todos los

responsables y usuarios de la organizacioacuten TI de las ventajas de una

correcta gestioacuten de todo el proceso de cambio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 22

Una versioacuten es un grupo de CIs de nueva creacioacuten o modificados que han sido

validados para su instalacioacuten en el entorno de produccioacuten Las especificaciones

funcionales y teacutecnicas de una versioacuten estaacuten determinadas en la RFC

correspondiente

23 Clasificacioacuten de las Versiones

Las versiones pueden clasificarse seguacuten 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 caracteriacutesticas teacutecnicas etc

Versiones menores que suelen implicar la correccioacuten 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 raacutepida

un error conocido

Como pueden llegar a existir muacuteltiples versiones es conveniente definir una

referencia o coacutedigo que los identifique uniacutevocamente El sistema

universalmente aceptado es

Versiones mayores 10 20 etc

Versiones menores 11 12 13 etc

Versiones de emergencia 111 112 etc

Aunque en algunos casos esta clasificacioacuten se refina auacuten maacutes (vea por

ejemplo en la ayuda la versioacuten de su navegador)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 23

En su ciclo de vida una versioacuten puede encontrase en diversos estados

desarrollo pruebas produccioacuten y archivado11

En la Figura 8 nos ilustra graacuteficamente la evolucioacuten temporal de una versioacuten

Figura 8 Evolucioacuten temporal de una versioacuten

El despliegue de nuevas versiones puede realizarse de diferentes maneras y

es responsabilidad de la Gestioacuten de Cambios el determinar la forma maacutes

conveniente de hacerlo Entre las opciones maacutes habituales cabe contar

Versioacuten delta soacutelo se testean e instalan los elementos modificados

Esta opcioacuten tiene como ventaja su mayor simplicidad pero conlleva el

peligro de que puedan aparecer problemas e incompatibilidades en el

entorno de produccioacuten

Versioacuten completa Se distribuyen todos los elementos afectados ya

hayan sido modificados o no Aunque esta opcioacuten es obviamente maacutes

trabajosa es maacutes improbable que se generen incidentes tras la

instalacioacuten si se han realizado las pruebas pertinentes

11

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 24

Paquete de Versiones La Gestioacuten 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 opcioacuten es obligada por incompatibilidades entre una nueva

versioacuten con software o hardware previamente instalado Pensemos por

ejemplo en la migracioacuten a un nuevo sistema operativo que requiere

hardware maacutes avanzado yo nuevos versiones de los programas

ofimaacuteticos

24 Visioacuten General

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI12

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten de Versiones se resumen

sucintamente en la siguiente Figura 9

12

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 25

Figura 9 Visioacuten General de la Gestioacuten de Versiones

25 Planificacioacuten

Es crucial establecer un marco general para el lanzamiento de nuevas

versiones que fije una metodologiacutea 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

especiacuteficos que tomen en cuenta las peculiaridades de cada caso

A la hora de planificar correctamente el lanzamiento de una nueva versioacuten se

deben de tomar en cuenta los siguientes factores

Coacutemo puede afectar la nueva versioacuten a otras aacutereas del entramado TI

Queacute CIs se veraacuten directa o indirectamente implicados durante y tras el

lanzamiento de la nueva versioacuten

Coacutemo ha de construirse el entorno de pruebas para que eacuteste sea fiel

reflejo del entorno de produccioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 26

Queacute planes de back-out son necesarios

Coacutemo y cuaacutendo se deben implementar los planes de back-out para

minimizar el posible impacto negativo sobre el servicio y la integridad del

sistema TI

Cuaacuteles son los recursos humanos y teacutecnicos necesarios para llevar a

cabo la implementacioacuten de la nueva versioacuten con garantiacuteas de eacutexito

Quieacutenes seraacuten los responsables directos en las diferentes etapas del

proceso

Queacute planes de comunicacioacuten yo formacioacuten deben desarrollarse para

que los usuarios esteacuten puntualmente informados y puedan percibir la

nueva versioacuten como una mejora

Queacute tipo de despliegue es el maacutes adecuado completo delta

sincronizado en todas los emplazamientos gradual

Cuaacutel es la vida media uacutetil esperada de la nueva versioacuten

Queacute impacto puede tener el proceso de lanzamiento de la nueva versioacuten

en la calidad del servicio

Si es posible establecer meacutetricas precisas que determinen el grado de

eacutexito del lanzamiento de la nueva versioacuten

26 Desarrollo

La Gestioacuten de Versiones es la encargada del disentildeo y construccioacuten de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes

A veces el desarrollo se realizara en la casa y muchas otras requeriraacute la

participacioacuten de proveedores externos En este segundo caso la tarea de la

Gestioacuten de Versiones seraacute la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC Asimismo la Gestioacuten de Versiones seraacute la responsable de todo el

proceso de configuracioacuten necesario

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

Parte integrante del desarrollo lo componen los planes de back-out asociados

Estos tendraacuten que tomar en cuenta la disponibilidad acordada con los clientes

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

Es importante que las pruebas incluyan los planes de back-out para

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

Que meacutetricas determinan la puesta en marcha de los planes de back-out

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

informada por el Service Desk de los comentarios quejas incidentes etc que

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

recibidas y que se tomen las medidas correctivas necesarias para minimizar el

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

Es frecuente y a su vez un grave error que cuando se aborden cuestiones de

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

Es inuacutetil disponer de un sofisticado servicio TI si los usuarios debido a una

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

remotos mediante moacutedulos de e-learning sobre el funcionamiento de la

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 12: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 12

ayuda a proporcionar soluciones raacutepidas 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 daacutendole 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 estaacute relacionada con lo que es el control del problema y la segunda

es con el control del error7

En lo que respecta a la fase de control del problema primero se tiene que

identificar el problema en base a alguna sintomatologiacutea ya que tenemos este

antecedente pasamos a la clasificacioacuten 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

estaacuten en el manual de procedimientos y en caso de no ser conocido se tendriacutea

que hacer una fase de investigacioacuten para ver queacute es lo que genera el problema

y maacutes tarde hacer un diagnostico ya que tenemos un diagnoacutestico 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 solucioacuten

y finalmente se va a hacer una evaluacioacuten para ver si se resolvioacute el problema

de raiacutez En caso de que si se funcione esta solucioacuten se pasa a la

documentacioacuten

Con lo que respecta a la segunda fase del modelo el control del error se hace

por medio de una identificacioacuten 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 clasificacioacuten y se recurre a una evaluacioacuten de que tanto dantildeo genero

o puede llegar a generar el error esto con la finalidad de cuantificar los

desperfectos que podriacutea llegar a causar en caso de que el error prevalezca y

no se solucione posteriormente se hace la resolucioacuten o correccioacuten del error

7 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 13

(este puede deberse a varios aspectos configuraciones falta de seguridad

inconsistencia de datos etc) y este modelo tiene una fase muy difiacutecil que es

determinar que problemas estaacuten 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 pasariacutea si

cambio algunos de los datos en la configuracioacuten del sistema se tendriacutea que

afectar el sistema de manera uniforme para que siga en equilibrio y no esteacute

cambiado en algunas partes y en otras que se quede como estaba antes

Figura 4 Proceso de manejo de problemas

173 PROCESO DE MANEJO DE CONFIGURACIONES

Su objetivo es proveer con informacioacuten real y actualizada de lo que se tiene

configurado e instalado en cada sistema del cliente

Este proceso es de los maacutes complejos como muestra la Figura 5 ya que se

mueve bajo cuatro veacutertices que son administracioacuten de cambios administracioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 14

de liberaciones administracioacuten de configuraciones y la administracioacuten de

procesos diversos8

El nivel de complejidad de este modelo es alto ya que influyen muchas

variables y muchas de ellas son dinaacutemicas entonces al cambiar una o varias

de ellas se afecta el sistema en general lo que hace que sea muy difiacutecil de

manipular Aunque es lo maacutes parecido a la realidad porque nuestro entorno es

dinaacutemico y las decisiones de unos afectan a otros Por ejemplo en lo que

respecta a la administracioacuten de cambios vemos que se relaciona directamente

con la administracioacuten de incidentes y de problemas lo que conlleva una

planeacioacuten identificacioacuten control seguimiento del status verificacioacuten y

auditoria de configuraciones lo que hace que haya muchas variables

En otro ejemplo la implementacioacuten de cambios implica que se tiene que hacer

la liberacioacuten y distribucioacuten de nuevas versiones esto de da por una fase de

planeacioacuten identificacioacuten control revisioacuten del status verificacioacuten y auditoria y

puede depender de la administracioacuten de las capacidades ya que si no se

cuenta con el software o con el hardware esta fase no se podriacutea llevar a cabo y

asiacute se hariacutea con todos los niveles hasta llegar al cierre del control de cambios

8 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 15

Figura 5 Proceso de manejo de configuraciones

174 PROCESO DE CONTROL DE CAMBIOS

El objetivo de este proceso es reducir los riesgos tanto teacutecnicos econoacutemicos y

de tiempo al momento de la realizacioacuten de los cambios

La Figura 6 al parecer es muy faacutecil 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 objetivos9

Primero vemos que tenemos un registro y clasificacioacuten del cambio que se tiene

que hacer se pasa a la fase de monitoreo y planeacioacuten si el rendimiento es

9 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 16

satisfactorio se da la aprobacioacuten del cambio y en caso de que el rendimiento

sea malo se pasa a la fase de reingenieriacutea 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 estaacute

probado se da la autorizacioacuten e implementacioacuten ya implementado se ve que no

se hayan tenido desviaciones y se ajusta a las necesidades actuales que

tambieacuten se le considera como revisioacuten post-implementacioacuten

Figura 6 Proceso de control de cambios

175 PROCESO DE MANEJO DE ENTREGAS

Su objetivo es planear y controlar exitosamente la instalacioacuten 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 transicioacuten que se da de acuerdo

a los ambientes por los que se va dando la evolucioacuten del proyecto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 17

En lo que respecta al ambiente de desarrollo vemos en la Figura 7 que se tiene

que hacer la liberacioacuten de las poliacuteticas la liberacioacuten de la planeacioacuten el disentildeo

loacutegico de la infraestructura que se va a implementar y la adquisicioacuten de

software y hardware estaacuten 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 construccioacuten y

liberacioacuten de las configuraciones (nivel loacutegico) se hacen las pruebas para

establecer los acuerdos de aceptacioacuten se da la aceptacioacuten total de versiones y

de modelos se arranca la planeacioacuten y finalmente las pruebas y

comunicaciones y en lo que es el ambiente real vemos que se da la

distribucioacuten e instalacioacuten 10

En la etapa del ambiente real es la que se ve de forma maacutes concreta ya que

muchas veces no tenemos idea de todo lo que pasa hasta antes de la

instalacioacuten

En el proceso de entrega del servicio es el punto en el que el usuario hace uno

del servicio y no sabe que detraacutes del servicio que estaacute 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 maacutes 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 planeacioacuten monitoreo anaacutelisis y por un sin fin de pruebas con la intencioacuten

de que en caso de que algo no funcione se deacute en la fase de pruebas

controladas y no en la fase de pruebas en ambiente real donde el mayor

afectado es el cliente

10

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 18

Figura 7 Proceso de manejo de entregas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 19

CAPITULO II

GESTION DE VERSIONES

21 Introduccioacuten y Objetivos

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten 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 implementacioacuten de cualquier

cambio

La Gestioacuten de Cambios es la encargada de aprobar y supervisar todo el

proceso pero es tarea especiacutefica de la Gestioacuten de Versiones el disentildear poner a

prueba e instalar en el entorno de produccioacuten los cambios preestablecidos

Todo ello requiere de una cuidadosa planificacioacuten y coordinacioacuten con el resto

de procesos asociados a la Gestioacuten de Servicios TI

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 20

Entre los principales objetivos de la Gestioacuten de Versiones se incluyen

Establecer una poliacutetica de implementacioacuten de nuevas versiones de

hardware y software

Implementar las nuevas versiones de software y hardware en el entorno

de produccioacuten tras su verificacioacuten en un entorno realista de pruebas

Garantizar que el proceso de cambio cumpla las especificaciones de la

RFC correspondiente

Asegurar en colaboracioacuten con la Gestioacuten de Cambios y

Configuraciones que todos los cambios se ven correctamente reflejados

en la CMDB

Archivar copias ideacutenticas del software en produccioacuten asiacute como de toda

su documentacioacuten asociada en la Biblioteca de Software Definitivo

(DSL)

Mantener actualizado el Depoacutesito de Hardware Definitivo (DHS)

22 Beneficios y Dificultades

Los beneficios de una correcta Gestioacuten 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 nuacutemero de incidentes por incompatibilidades con otro

software o hardware instalado

El proceso de pruebas asociado no soacutelo permite asegurar la calidad del

software y hardware a instalar sino que tambieacuten permite conocer la

opinioacuten 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 nuacutemero de copias de software ilegales

Control centralizado del software y hardware desplegado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 21

Proteccioacuten contra virus y problemas asociados a versiones de software

incontroladas

Las principales dificultades con las que topa la Gestioacuten de Versiones son

No existe una clara asignacioacuten de responsabilidades yo la organizacioacuten

TI no acepta la figura dominante de la Gestioacuten de Versiones en todo el

proceso de implementacioacuten 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 centralizacioacuten del

proceso de cambio Es habitual que existan reticencias a adoptar

sistemas estandarizados en toda la organizacioacuten sobre todo cuando

eacutesta no ha sido la poliacutetica tradicional de la misma

Se realizan cambios sin tener en cuenta a la Gestioacuten de Versiones

argumentado que estos soacutelo son responsabilidad de un determinado

grupo de trabajo o que su urgencia requeriacutea de ello

Hay resistencias a aceptar posibles planes de back-out Ciertos

entornos de produccioacuten pueden elegir ignorar lo problemas que una

nueva versioacuten puede provocar en otras aacutereas y resistirse a volver a la

uacuteltima versioacuten estable

La implementacioacuten sincronizada de versiones en entornos altamente

distribuidos

La solucioacuten a estos problemas pasa por

Un firme compromiso de la organizacioacuten con la Gestioacuten de Versiones y

sus responsables

Un adecuado plan de comunicacioacuten que informe a todos los

responsables y usuarios de la organizacioacuten TI de las ventajas de una

correcta gestioacuten de todo el proceso de cambio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 22

Una versioacuten es un grupo de CIs de nueva creacioacuten o modificados que han sido

validados para su instalacioacuten en el entorno de produccioacuten Las especificaciones

funcionales y teacutecnicas de una versioacuten estaacuten determinadas en la RFC

correspondiente

23 Clasificacioacuten de las Versiones

Las versiones pueden clasificarse seguacuten 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 caracteriacutesticas teacutecnicas etc

Versiones menores que suelen implicar la correccioacuten 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 raacutepida

un error conocido

Como pueden llegar a existir muacuteltiples versiones es conveniente definir una

referencia o coacutedigo que los identifique uniacutevocamente El sistema

universalmente aceptado es

Versiones mayores 10 20 etc

Versiones menores 11 12 13 etc

Versiones de emergencia 111 112 etc

Aunque en algunos casos esta clasificacioacuten se refina auacuten maacutes (vea por

ejemplo en la ayuda la versioacuten de su navegador)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 23

En su ciclo de vida una versioacuten puede encontrase en diversos estados

desarrollo pruebas produccioacuten y archivado11

En la Figura 8 nos ilustra graacuteficamente la evolucioacuten temporal de una versioacuten

Figura 8 Evolucioacuten temporal de una versioacuten

El despliegue de nuevas versiones puede realizarse de diferentes maneras y

es responsabilidad de la Gestioacuten de Cambios el determinar la forma maacutes

conveniente de hacerlo Entre las opciones maacutes habituales cabe contar

Versioacuten delta soacutelo se testean e instalan los elementos modificados

Esta opcioacuten tiene como ventaja su mayor simplicidad pero conlleva el

peligro de que puedan aparecer problemas e incompatibilidades en el

entorno de produccioacuten

Versioacuten completa Se distribuyen todos los elementos afectados ya

hayan sido modificados o no Aunque esta opcioacuten es obviamente maacutes

trabajosa es maacutes improbable que se generen incidentes tras la

instalacioacuten si se han realizado las pruebas pertinentes

11

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 24

Paquete de Versiones La Gestioacuten 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 opcioacuten es obligada por incompatibilidades entre una nueva

versioacuten con software o hardware previamente instalado Pensemos por

ejemplo en la migracioacuten a un nuevo sistema operativo que requiere

hardware maacutes avanzado yo nuevos versiones de los programas

ofimaacuteticos

24 Visioacuten General

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI12

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten de Versiones se resumen

sucintamente en la siguiente Figura 9

12

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 25

Figura 9 Visioacuten General de la Gestioacuten de Versiones

25 Planificacioacuten

Es crucial establecer un marco general para el lanzamiento de nuevas

versiones que fije una metodologiacutea 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

especiacuteficos que tomen en cuenta las peculiaridades de cada caso

A la hora de planificar correctamente el lanzamiento de una nueva versioacuten se

deben de tomar en cuenta los siguientes factores

Coacutemo puede afectar la nueva versioacuten a otras aacutereas del entramado TI

Queacute CIs se veraacuten directa o indirectamente implicados durante y tras el

lanzamiento de la nueva versioacuten

Coacutemo ha de construirse el entorno de pruebas para que eacuteste sea fiel

reflejo del entorno de produccioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 26

Queacute planes de back-out son necesarios

Coacutemo y cuaacutendo se deben implementar los planes de back-out para

minimizar el posible impacto negativo sobre el servicio y la integridad del

sistema TI

Cuaacuteles son los recursos humanos y teacutecnicos necesarios para llevar a

cabo la implementacioacuten de la nueva versioacuten con garantiacuteas de eacutexito

Quieacutenes seraacuten los responsables directos en las diferentes etapas del

proceso

Queacute planes de comunicacioacuten yo formacioacuten deben desarrollarse para

que los usuarios esteacuten puntualmente informados y puedan percibir la

nueva versioacuten como una mejora

Queacute tipo de despliegue es el maacutes adecuado completo delta

sincronizado en todas los emplazamientos gradual

Cuaacutel es la vida media uacutetil esperada de la nueva versioacuten

Queacute impacto puede tener el proceso de lanzamiento de la nueva versioacuten

en la calidad del servicio

Si es posible establecer meacutetricas precisas que determinen el grado de

eacutexito del lanzamiento de la nueva versioacuten

26 Desarrollo

La Gestioacuten de Versiones es la encargada del disentildeo y construccioacuten de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes

A veces el desarrollo se realizara en la casa y muchas otras requeriraacute la

participacioacuten de proveedores externos En este segundo caso la tarea de la

Gestioacuten de Versiones seraacute la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC Asimismo la Gestioacuten de Versiones seraacute la responsable de todo el

proceso de configuracioacuten necesario

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

Parte integrante del desarrollo lo componen los planes de back-out asociados

Estos tendraacuten que tomar en cuenta la disponibilidad acordada con los clientes

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

Es importante que las pruebas incluyan los planes de back-out para

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

Que meacutetricas determinan la puesta en marcha de los planes de back-out

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

informada por el Service Desk de los comentarios quejas incidentes etc que

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

recibidas y que se tomen las medidas correctivas necesarias para minimizar el

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

Es frecuente y a su vez un grave error que cuando se aborden cuestiones de

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

Es inuacutetil disponer de un sofisticado servicio TI si los usuarios debido a una

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

remotos mediante moacutedulos de e-learning sobre el funcionamiento de la

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 13: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 13

(este puede deberse a varios aspectos configuraciones falta de seguridad

inconsistencia de datos etc) y este modelo tiene una fase muy difiacutecil que es

determinar que problemas estaacuten 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 pasariacutea si

cambio algunos de los datos en la configuracioacuten del sistema se tendriacutea que

afectar el sistema de manera uniforme para que siga en equilibrio y no esteacute

cambiado en algunas partes y en otras que se quede como estaba antes

Figura 4 Proceso de manejo de problemas

173 PROCESO DE MANEJO DE CONFIGURACIONES

Su objetivo es proveer con informacioacuten real y actualizada de lo que se tiene

configurado e instalado en cada sistema del cliente

Este proceso es de los maacutes complejos como muestra la Figura 5 ya que se

mueve bajo cuatro veacutertices que son administracioacuten de cambios administracioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 14

de liberaciones administracioacuten de configuraciones y la administracioacuten de

procesos diversos8

El nivel de complejidad de este modelo es alto ya que influyen muchas

variables y muchas de ellas son dinaacutemicas entonces al cambiar una o varias

de ellas se afecta el sistema en general lo que hace que sea muy difiacutecil de

manipular Aunque es lo maacutes parecido a la realidad porque nuestro entorno es

dinaacutemico y las decisiones de unos afectan a otros Por ejemplo en lo que

respecta a la administracioacuten de cambios vemos que se relaciona directamente

con la administracioacuten de incidentes y de problemas lo que conlleva una

planeacioacuten identificacioacuten control seguimiento del status verificacioacuten y

auditoria de configuraciones lo que hace que haya muchas variables

En otro ejemplo la implementacioacuten de cambios implica que se tiene que hacer

la liberacioacuten y distribucioacuten de nuevas versiones esto de da por una fase de

planeacioacuten identificacioacuten control revisioacuten del status verificacioacuten y auditoria y

puede depender de la administracioacuten de las capacidades ya que si no se

cuenta con el software o con el hardware esta fase no se podriacutea llevar a cabo y

asiacute se hariacutea con todos los niveles hasta llegar al cierre del control de cambios

8 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 15

Figura 5 Proceso de manejo de configuraciones

174 PROCESO DE CONTROL DE CAMBIOS

El objetivo de este proceso es reducir los riesgos tanto teacutecnicos econoacutemicos y

de tiempo al momento de la realizacioacuten de los cambios

La Figura 6 al parecer es muy faacutecil 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 objetivos9

Primero vemos que tenemos un registro y clasificacioacuten del cambio que se tiene

que hacer se pasa a la fase de monitoreo y planeacioacuten si el rendimiento es

9 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 16

satisfactorio se da la aprobacioacuten del cambio y en caso de que el rendimiento

sea malo se pasa a la fase de reingenieriacutea 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 estaacute

probado se da la autorizacioacuten e implementacioacuten ya implementado se ve que no

se hayan tenido desviaciones y se ajusta a las necesidades actuales que

tambieacuten se le considera como revisioacuten post-implementacioacuten

Figura 6 Proceso de control de cambios

175 PROCESO DE MANEJO DE ENTREGAS

Su objetivo es planear y controlar exitosamente la instalacioacuten 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 transicioacuten que se da de acuerdo

a los ambientes por los que se va dando la evolucioacuten del proyecto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 17

En lo que respecta al ambiente de desarrollo vemos en la Figura 7 que se tiene

que hacer la liberacioacuten de las poliacuteticas la liberacioacuten de la planeacioacuten el disentildeo

loacutegico de la infraestructura que se va a implementar y la adquisicioacuten de

software y hardware estaacuten 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 construccioacuten y

liberacioacuten de las configuraciones (nivel loacutegico) se hacen las pruebas para

establecer los acuerdos de aceptacioacuten se da la aceptacioacuten total de versiones y

de modelos se arranca la planeacioacuten y finalmente las pruebas y

comunicaciones y en lo que es el ambiente real vemos que se da la

distribucioacuten e instalacioacuten 10

En la etapa del ambiente real es la que se ve de forma maacutes concreta ya que

muchas veces no tenemos idea de todo lo que pasa hasta antes de la

instalacioacuten

En el proceso de entrega del servicio es el punto en el que el usuario hace uno

del servicio y no sabe que detraacutes del servicio que estaacute 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 maacutes 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 planeacioacuten monitoreo anaacutelisis y por un sin fin de pruebas con la intencioacuten

de que en caso de que algo no funcione se deacute en la fase de pruebas

controladas y no en la fase de pruebas en ambiente real donde el mayor

afectado es el cliente

10

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 18

Figura 7 Proceso de manejo de entregas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 19

CAPITULO II

GESTION DE VERSIONES

21 Introduccioacuten y Objetivos

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten 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 implementacioacuten de cualquier

cambio

La Gestioacuten de Cambios es la encargada de aprobar y supervisar todo el

proceso pero es tarea especiacutefica de la Gestioacuten de Versiones el disentildear poner a

prueba e instalar en el entorno de produccioacuten los cambios preestablecidos

Todo ello requiere de una cuidadosa planificacioacuten y coordinacioacuten con el resto

de procesos asociados a la Gestioacuten de Servicios TI

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 20

Entre los principales objetivos de la Gestioacuten de Versiones se incluyen

Establecer una poliacutetica de implementacioacuten de nuevas versiones de

hardware y software

Implementar las nuevas versiones de software y hardware en el entorno

de produccioacuten tras su verificacioacuten en un entorno realista de pruebas

Garantizar que el proceso de cambio cumpla las especificaciones de la

RFC correspondiente

Asegurar en colaboracioacuten con la Gestioacuten de Cambios y

Configuraciones que todos los cambios se ven correctamente reflejados

en la CMDB

Archivar copias ideacutenticas del software en produccioacuten asiacute como de toda

su documentacioacuten asociada en la Biblioteca de Software Definitivo

(DSL)

Mantener actualizado el Depoacutesito de Hardware Definitivo (DHS)

22 Beneficios y Dificultades

Los beneficios de una correcta Gestioacuten 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 nuacutemero de incidentes por incompatibilidades con otro

software o hardware instalado

El proceso de pruebas asociado no soacutelo permite asegurar la calidad del

software y hardware a instalar sino que tambieacuten permite conocer la

opinioacuten 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 nuacutemero de copias de software ilegales

Control centralizado del software y hardware desplegado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 21

Proteccioacuten contra virus y problemas asociados a versiones de software

incontroladas

Las principales dificultades con las que topa la Gestioacuten de Versiones son

No existe una clara asignacioacuten de responsabilidades yo la organizacioacuten

TI no acepta la figura dominante de la Gestioacuten de Versiones en todo el

proceso de implementacioacuten 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 centralizacioacuten del

proceso de cambio Es habitual que existan reticencias a adoptar

sistemas estandarizados en toda la organizacioacuten sobre todo cuando

eacutesta no ha sido la poliacutetica tradicional de la misma

Se realizan cambios sin tener en cuenta a la Gestioacuten de Versiones

argumentado que estos soacutelo son responsabilidad de un determinado

grupo de trabajo o que su urgencia requeriacutea de ello

Hay resistencias a aceptar posibles planes de back-out Ciertos

entornos de produccioacuten pueden elegir ignorar lo problemas que una

nueva versioacuten puede provocar en otras aacutereas y resistirse a volver a la

uacuteltima versioacuten estable

La implementacioacuten sincronizada de versiones en entornos altamente

distribuidos

La solucioacuten a estos problemas pasa por

Un firme compromiso de la organizacioacuten con la Gestioacuten de Versiones y

sus responsables

Un adecuado plan de comunicacioacuten que informe a todos los

responsables y usuarios de la organizacioacuten TI de las ventajas de una

correcta gestioacuten de todo el proceso de cambio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 22

Una versioacuten es un grupo de CIs de nueva creacioacuten o modificados que han sido

validados para su instalacioacuten en el entorno de produccioacuten Las especificaciones

funcionales y teacutecnicas de una versioacuten estaacuten determinadas en la RFC

correspondiente

23 Clasificacioacuten de las Versiones

Las versiones pueden clasificarse seguacuten 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 caracteriacutesticas teacutecnicas etc

Versiones menores que suelen implicar la correccioacuten 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 raacutepida

un error conocido

Como pueden llegar a existir muacuteltiples versiones es conveniente definir una

referencia o coacutedigo que los identifique uniacutevocamente El sistema

universalmente aceptado es

Versiones mayores 10 20 etc

Versiones menores 11 12 13 etc

Versiones de emergencia 111 112 etc

Aunque en algunos casos esta clasificacioacuten se refina auacuten maacutes (vea por

ejemplo en la ayuda la versioacuten de su navegador)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 23

En su ciclo de vida una versioacuten puede encontrase en diversos estados

desarrollo pruebas produccioacuten y archivado11

En la Figura 8 nos ilustra graacuteficamente la evolucioacuten temporal de una versioacuten

Figura 8 Evolucioacuten temporal de una versioacuten

El despliegue de nuevas versiones puede realizarse de diferentes maneras y

es responsabilidad de la Gestioacuten de Cambios el determinar la forma maacutes

conveniente de hacerlo Entre las opciones maacutes habituales cabe contar

Versioacuten delta soacutelo se testean e instalan los elementos modificados

Esta opcioacuten tiene como ventaja su mayor simplicidad pero conlleva el

peligro de que puedan aparecer problemas e incompatibilidades en el

entorno de produccioacuten

Versioacuten completa Se distribuyen todos los elementos afectados ya

hayan sido modificados o no Aunque esta opcioacuten es obviamente maacutes

trabajosa es maacutes improbable que se generen incidentes tras la

instalacioacuten si se han realizado las pruebas pertinentes

11

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 24

Paquete de Versiones La Gestioacuten 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 opcioacuten es obligada por incompatibilidades entre una nueva

versioacuten con software o hardware previamente instalado Pensemos por

ejemplo en la migracioacuten a un nuevo sistema operativo que requiere

hardware maacutes avanzado yo nuevos versiones de los programas

ofimaacuteticos

24 Visioacuten General

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI12

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten de Versiones se resumen

sucintamente en la siguiente Figura 9

12

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 25

Figura 9 Visioacuten General de la Gestioacuten de Versiones

25 Planificacioacuten

Es crucial establecer un marco general para el lanzamiento de nuevas

versiones que fije una metodologiacutea 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

especiacuteficos que tomen en cuenta las peculiaridades de cada caso

A la hora de planificar correctamente el lanzamiento de una nueva versioacuten se

deben de tomar en cuenta los siguientes factores

Coacutemo puede afectar la nueva versioacuten a otras aacutereas del entramado TI

Queacute CIs se veraacuten directa o indirectamente implicados durante y tras el

lanzamiento de la nueva versioacuten

Coacutemo ha de construirse el entorno de pruebas para que eacuteste sea fiel

reflejo del entorno de produccioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 26

Queacute planes de back-out son necesarios

Coacutemo y cuaacutendo se deben implementar los planes de back-out para

minimizar el posible impacto negativo sobre el servicio y la integridad del

sistema TI

Cuaacuteles son los recursos humanos y teacutecnicos necesarios para llevar a

cabo la implementacioacuten de la nueva versioacuten con garantiacuteas de eacutexito

Quieacutenes seraacuten los responsables directos en las diferentes etapas del

proceso

Queacute planes de comunicacioacuten yo formacioacuten deben desarrollarse para

que los usuarios esteacuten puntualmente informados y puedan percibir la

nueva versioacuten como una mejora

Queacute tipo de despliegue es el maacutes adecuado completo delta

sincronizado en todas los emplazamientos gradual

Cuaacutel es la vida media uacutetil esperada de la nueva versioacuten

Queacute impacto puede tener el proceso de lanzamiento de la nueva versioacuten

en la calidad del servicio

Si es posible establecer meacutetricas precisas que determinen el grado de

eacutexito del lanzamiento de la nueva versioacuten

26 Desarrollo

La Gestioacuten de Versiones es la encargada del disentildeo y construccioacuten de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes

A veces el desarrollo se realizara en la casa y muchas otras requeriraacute la

participacioacuten de proveedores externos En este segundo caso la tarea de la

Gestioacuten de Versiones seraacute la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC Asimismo la Gestioacuten de Versiones seraacute la responsable de todo el

proceso de configuracioacuten necesario

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

Parte integrante del desarrollo lo componen los planes de back-out asociados

Estos tendraacuten que tomar en cuenta la disponibilidad acordada con los clientes

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

Es importante que las pruebas incluyan los planes de back-out para

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

Que meacutetricas determinan la puesta en marcha de los planes de back-out

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

informada por el Service Desk de los comentarios quejas incidentes etc que

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

recibidas y que se tomen las medidas correctivas necesarias para minimizar el

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

Es frecuente y a su vez un grave error que cuando se aborden cuestiones de

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

Es inuacutetil disponer de un sofisticado servicio TI si los usuarios debido a una

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

remotos mediante moacutedulos de e-learning sobre el funcionamiento de la

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 14: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 14

de liberaciones administracioacuten de configuraciones y la administracioacuten de

procesos diversos8

El nivel de complejidad de este modelo es alto ya que influyen muchas

variables y muchas de ellas son dinaacutemicas entonces al cambiar una o varias

de ellas se afecta el sistema en general lo que hace que sea muy difiacutecil de

manipular Aunque es lo maacutes parecido a la realidad porque nuestro entorno es

dinaacutemico y las decisiones de unos afectan a otros Por ejemplo en lo que

respecta a la administracioacuten de cambios vemos que se relaciona directamente

con la administracioacuten de incidentes y de problemas lo que conlleva una

planeacioacuten identificacioacuten control seguimiento del status verificacioacuten y

auditoria de configuraciones lo que hace que haya muchas variables

En otro ejemplo la implementacioacuten de cambios implica que se tiene que hacer

la liberacioacuten y distribucioacuten de nuevas versiones esto de da por una fase de

planeacioacuten identificacioacuten control revisioacuten del status verificacioacuten y auditoria y

puede depender de la administracioacuten de las capacidades ya que si no se

cuenta con el software o con el hardware esta fase no se podriacutea llevar a cabo y

asiacute se hariacutea con todos los niveles hasta llegar al cierre del control de cambios

8 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 15

Figura 5 Proceso de manejo de configuraciones

174 PROCESO DE CONTROL DE CAMBIOS

El objetivo de este proceso es reducir los riesgos tanto teacutecnicos econoacutemicos y

de tiempo al momento de la realizacioacuten de los cambios

La Figura 6 al parecer es muy faacutecil 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 objetivos9

Primero vemos que tenemos un registro y clasificacioacuten del cambio que se tiene

que hacer se pasa a la fase de monitoreo y planeacioacuten si el rendimiento es

9 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 16

satisfactorio se da la aprobacioacuten del cambio y en caso de que el rendimiento

sea malo se pasa a la fase de reingenieriacutea 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 estaacute

probado se da la autorizacioacuten e implementacioacuten ya implementado se ve que no

se hayan tenido desviaciones y se ajusta a las necesidades actuales que

tambieacuten se le considera como revisioacuten post-implementacioacuten

Figura 6 Proceso de control de cambios

175 PROCESO DE MANEJO DE ENTREGAS

Su objetivo es planear y controlar exitosamente la instalacioacuten 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 transicioacuten que se da de acuerdo

a los ambientes por los que se va dando la evolucioacuten del proyecto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 17

En lo que respecta al ambiente de desarrollo vemos en la Figura 7 que se tiene

que hacer la liberacioacuten de las poliacuteticas la liberacioacuten de la planeacioacuten el disentildeo

loacutegico de la infraestructura que se va a implementar y la adquisicioacuten de

software y hardware estaacuten 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 construccioacuten y

liberacioacuten de las configuraciones (nivel loacutegico) se hacen las pruebas para

establecer los acuerdos de aceptacioacuten se da la aceptacioacuten total de versiones y

de modelos se arranca la planeacioacuten y finalmente las pruebas y

comunicaciones y en lo que es el ambiente real vemos que se da la

distribucioacuten e instalacioacuten 10

En la etapa del ambiente real es la que se ve de forma maacutes concreta ya que

muchas veces no tenemos idea de todo lo que pasa hasta antes de la

instalacioacuten

En el proceso de entrega del servicio es el punto en el que el usuario hace uno

del servicio y no sabe que detraacutes del servicio que estaacute 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 maacutes 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 planeacioacuten monitoreo anaacutelisis y por un sin fin de pruebas con la intencioacuten

de que en caso de que algo no funcione se deacute en la fase de pruebas

controladas y no en la fase de pruebas en ambiente real donde el mayor

afectado es el cliente

10

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 18

Figura 7 Proceso de manejo de entregas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 19

CAPITULO II

GESTION DE VERSIONES

21 Introduccioacuten y Objetivos

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten 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 implementacioacuten de cualquier

cambio

La Gestioacuten de Cambios es la encargada de aprobar y supervisar todo el

proceso pero es tarea especiacutefica de la Gestioacuten de Versiones el disentildear poner a

prueba e instalar en el entorno de produccioacuten los cambios preestablecidos

Todo ello requiere de una cuidadosa planificacioacuten y coordinacioacuten con el resto

de procesos asociados a la Gestioacuten de Servicios TI

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 20

Entre los principales objetivos de la Gestioacuten de Versiones se incluyen

Establecer una poliacutetica de implementacioacuten de nuevas versiones de

hardware y software

Implementar las nuevas versiones de software y hardware en el entorno

de produccioacuten tras su verificacioacuten en un entorno realista de pruebas

Garantizar que el proceso de cambio cumpla las especificaciones de la

RFC correspondiente

Asegurar en colaboracioacuten con la Gestioacuten de Cambios y

Configuraciones que todos los cambios se ven correctamente reflejados

en la CMDB

Archivar copias ideacutenticas del software en produccioacuten asiacute como de toda

su documentacioacuten asociada en la Biblioteca de Software Definitivo

(DSL)

Mantener actualizado el Depoacutesito de Hardware Definitivo (DHS)

22 Beneficios y Dificultades

Los beneficios de una correcta Gestioacuten 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 nuacutemero de incidentes por incompatibilidades con otro

software o hardware instalado

El proceso de pruebas asociado no soacutelo permite asegurar la calidad del

software y hardware a instalar sino que tambieacuten permite conocer la

opinioacuten 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 nuacutemero de copias de software ilegales

Control centralizado del software y hardware desplegado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 21

Proteccioacuten contra virus y problemas asociados a versiones de software

incontroladas

Las principales dificultades con las que topa la Gestioacuten de Versiones son

No existe una clara asignacioacuten de responsabilidades yo la organizacioacuten

TI no acepta la figura dominante de la Gestioacuten de Versiones en todo el

proceso de implementacioacuten 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 centralizacioacuten del

proceso de cambio Es habitual que existan reticencias a adoptar

sistemas estandarizados en toda la organizacioacuten sobre todo cuando

eacutesta no ha sido la poliacutetica tradicional de la misma

Se realizan cambios sin tener en cuenta a la Gestioacuten de Versiones

argumentado que estos soacutelo son responsabilidad de un determinado

grupo de trabajo o que su urgencia requeriacutea de ello

Hay resistencias a aceptar posibles planes de back-out Ciertos

entornos de produccioacuten pueden elegir ignorar lo problemas que una

nueva versioacuten puede provocar en otras aacutereas y resistirse a volver a la

uacuteltima versioacuten estable

La implementacioacuten sincronizada de versiones en entornos altamente

distribuidos

La solucioacuten a estos problemas pasa por

Un firme compromiso de la organizacioacuten con la Gestioacuten de Versiones y

sus responsables

Un adecuado plan de comunicacioacuten que informe a todos los

responsables y usuarios de la organizacioacuten TI de las ventajas de una

correcta gestioacuten de todo el proceso de cambio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 22

Una versioacuten es un grupo de CIs de nueva creacioacuten o modificados que han sido

validados para su instalacioacuten en el entorno de produccioacuten Las especificaciones

funcionales y teacutecnicas de una versioacuten estaacuten determinadas en la RFC

correspondiente

23 Clasificacioacuten de las Versiones

Las versiones pueden clasificarse seguacuten 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 caracteriacutesticas teacutecnicas etc

Versiones menores que suelen implicar la correccioacuten 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 raacutepida

un error conocido

Como pueden llegar a existir muacuteltiples versiones es conveniente definir una

referencia o coacutedigo que los identifique uniacutevocamente El sistema

universalmente aceptado es

Versiones mayores 10 20 etc

Versiones menores 11 12 13 etc

Versiones de emergencia 111 112 etc

Aunque en algunos casos esta clasificacioacuten se refina auacuten maacutes (vea por

ejemplo en la ayuda la versioacuten de su navegador)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 23

En su ciclo de vida una versioacuten puede encontrase en diversos estados

desarrollo pruebas produccioacuten y archivado11

En la Figura 8 nos ilustra graacuteficamente la evolucioacuten temporal de una versioacuten

Figura 8 Evolucioacuten temporal de una versioacuten

El despliegue de nuevas versiones puede realizarse de diferentes maneras y

es responsabilidad de la Gestioacuten de Cambios el determinar la forma maacutes

conveniente de hacerlo Entre las opciones maacutes habituales cabe contar

Versioacuten delta soacutelo se testean e instalan los elementos modificados

Esta opcioacuten tiene como ventaja su mayor simplicidad pero conlleva el

peligro de que puedan aparecer problemas e incompatibilidades en el

entorno de produccioacuten

Versioacuten completa Se distribuyen todos los elementos afectados ya

hayan sido modificados o no Aunque esta opcioacuten es obviamente maacutes

trabajosa es maacutes improbable que se generen incidentes tras la

instalacioacuten si se han realizado las pruebas pertinentes

11

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 24

Paquete de Versiones La Gestioacuten 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 opcioacuten es obligada por incompatibilidades entre una nueva

versioacuten con software o hardware previamente instalado Pensemos por

ejemplo en la migracioacuten a un nuevo sistema operativo que requiere

hardware maacutes avanzado yo nuevos versiones de los programas

ofimaacuteticos

24 Visioacuten General

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI12

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten de Versiones se resumen

sucintamente en la siguiente Figura 9

12

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 25

Figura 9 Visioacuten General de la Gestioacuten de Versiones

25 Planificacioacuten

Es crucial establecer un marco general para el lanzamiento de nuevas

versiones que fije una metodologiacutea 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

especiacuteficos que tomen en cuenta las peculiaridades de cada caso

A la hora de planificar correctamente el lanzamiento de una nueva versioacuten se

deben de tomar en cuenta los siguientes factores

Coacutemo puede afectar la nueva versioacuten a otras aacutereas del entramado TI

Queacute CIs se veraacuten directa o indirectamente implicados durante y tras el

lanzamiento de la nueva versioacuten

Coacutemo ha de construirse el entorno de pruebas para que eacuteste sea fiel

reflejo del entorno de produccioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 26

Queacute planes de back-out son necesarios

Coacutemo y cuaacutendo se deben implementar los planes de back-out para

minimizar el posible impacto negativo sobre el servicio y la integridad del

sistema TI

Cuaacuteles son los recursos humanos y teacutecnicos necesarios para llevar a

cabo la implementacioacuten de la nueva versioacuten con garantiacuteas de eacutexito

Quieacutenes seraacuten los responsables directos en las diferentes etapas del

proceso

Queacute planes de comunicacioacuten yo formacioacuten deben desarrollarse para

que los usuarios esteacuten puntualmente informados y puedan percibir la

nueva versioacuten como una mejora

Queacute tipo de despliegue es el maacutes adecuado completo delta

sincronizado en todas los emplazamientos gradual

Cuaacutel es la vida media uacutetil esperada de la nueva versioacuten

Queacute impacto puede tener el proceso de lanzamiento de la nueva versioacuten

en la calidad del servicio

Si es posible establecer meacutetricas precisas que determinen el grado de

eacutexito del lanzamiento de la nueva versioacuten

26 Desarrollo

La Gestioacuten de Versiones es la encargada del disentildeo y construccioacuten de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes

A veces el desarrollo se realizara en la casa y muchas otras requeriraacute la

participacioacuten de proveedores externos En este segundo caso la tarea de la

Gestioacuten de Versiones seraacute la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC Asimismo la Gestioacuten de Versiones seraacute la responsable de todo el

proceso de configuracioacuten necesario

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

Parte integrante del desarrollo lo componen los planes de back-out asociados

Estos tendraacuten que tomar en cuenta la disponibilidad acordada con los clientes

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

Es importante que las pruebas incluyan los planes de back-out para

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

Que meacutetricas determinan la puesta en marcha de los planes de back-out

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

informada por el Service Desk de los comentarios quejas incidentes etc que

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

recibidas y que se tomen las medidas correctivas necesarias para minimizar el

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

Es frecuente y a su vez un grave error que cuando se aborden cuestiones de

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

Es inuacutetil disponer de un sofisticado servicio TI si los usuarios debido a una

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

remotos mediante moacutedulos de e-learning sobre el funcionamiento de la

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 15: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 15

Figura 5 Proceso de manejo de configuraciones

174 PROCESO DE CONTROL DE CAMBIOS

El objetivo de este proceso es reducir los riesgos tanto teacutecnicos econoacutemicos y

de tiempo al momento de la realizacioacuten de los cambios

La Figura 6 al parecer es muy faacutecil 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 objetivos9

Primero vemos que tenemos un registro y clasificacioacuten del cambio que se tiene

que hacer se pasa a la fase de monitoreo y planeacioacuten si el rendimiento es

9 httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 16

satisfactorio se da la aprobacioacuten del cambio y en caso de que el rendimiento

sea malo se pasa a la fase de reingenieriacutea 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 estaacute

probado se da la autorizacioacuten e implementacioacuten ya implementado se ve que no

se hayan tenido desviaciones y se ajusta a las necesidades actuales que

tambieacuten se le considera como revisioacuten post-implementacioacuten

Figura 6 Proceso de control de cambios

175 PROCESO DE MANEJO DE ENTREGAS

Su objetivo es planear y controlar exitosamente la instalacioacuten 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 transicioacuten que se da de acuerdo

a los ambientes por los que se va dando la evolucioacuten del proyecto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 17

En lo que respecta al ambiente de desarrollo vemos en la Figura 7 que se tiene

que hacer la liberacioacuten de las poliacuteticas la liberacioacuten de la planeacioacuten el disentildeo

loacutegico de la infraestructura que se va a implementar y la adquisicioacuten de

software y hardware estaacuten 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 construccioacuten y

liberacioacuten de las configuraciones (nivel loacutegico) se hacen las pruebas para

establecer los acuerdos de aceptacioacuten se da la aceptacioacuten total de versiones y

de modelos se arranca la planeacioacuten y finalmente las pruebas y

comunicaciones y en lo que es el ambiente real vemos que se da la

distribucioacuten e instalacioacuten 10

En la etapa del ambiente real es la que se ve de forma maacutes concreta ya que

muchas veces no tenemos idea de todo lo que pasa hasta antes de la

instalacioacuten

En el proceso de entrega del servicio es el punto en el que el usuario hace uno

del servicio y no sabe que detraacutes del servicio que estaacute 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 maacutes 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 planeacioacuten monitoreo anaacutelisis y por un sin fin de pruebas con la intencioacuten

de que en caso de que algo no funcione se deacute en la fase de pruebas

controladas y no en la fase de pruebas en ambiente real donde el mayor

afectado es el cliente

10

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 18

Figura 7 Proceso de manejo de entregas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 19

CAPITULO II

GESTION DE VERSIONES

21 Introduccioacuten y Objetivos

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten 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 implementacioacuten de cualquier

cambio

La Gestioacuten de Cambios es la encargada de aprobar y supervisar todo el

proceso pero es tarea especiacutefica de la Gestioacuten de Versiones el disentildear poner a

prueba e instalar en el entorno de produccioacuten los cambios preestablecidos

Todo ello requiere de una cuidadosa planificacioacuten y coordinacioacuten con el resto

de procesos asociados a la Gestioacuten de Servicios TI

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 20

Entre los principales objetivos de la Gestioacuten de Versiones se incluyen

Establecer una poliacutetica de implementacioacuten de nuevas versiones de

hardware y software

Implementar las nuevas versiones de software y hardware en el entorno

de produccioacuten tras su verificacioacuten en un entorno realista de pruebas

Garantizar que el proceso de cambio cumpla las especificaciones de la

RFC correspondiente

Asegurar en colaboracioacuten con la Gestioacuten de Cambios y

Configuraciones que todos los cambios se ven correctamente reflejados

en la CMDB

Archivar copias ideacutenticas del software en produccioacuten asiacute como de toda

su documentacioacuten asociada en la Biblioteca de Software Definitivo

(DSL)

Mantener actualizado el Depoacutesito de Hardware Definitivo (DHS)

22 Beneficios y Dificultades

Los beneficios de una correcta Gestioacuten 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 nuacutemero de incidentes por incompatibilidades con otro

software o hardware instalado

El proceso de pruebas asociado no soacutelo permite asegurar la calidad del

software y hardware a instalar sino que tambieacuten permite conocer la

opinioacuten 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 nuacutemero de copias de software ilegales

Control centralizado del software y hardware desplegado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 21

Proteccioacuten contra virus y problemas asociados a versiones de software

incontroladas

Las principales dificultades con las que topa la Gestioacuten de Versiones son

No existe una clara asignacioacuten de responsabilidades yo la organizacioacuten

TI no acepta la figura dominante de la Gestioacuten de Versiones en todo el

proceso de implementacioacuten 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 centralizacioacuten del

proceso de cambio Es habitual que existan reticencias a adoptar

sistemas estandarizados en toda la organizacioacuten sobre todo cuando

eacutesta no ha sido la poliacutetica tradicional de la misma

Se realizan cambios sin tener en cuenta a la Gestioacuten de Versiones

argumentado que estos soacutelo son responsabilidad de un determinado

grupo de trabajo o que su urgencia requeriacutea de ello

Hay resistencias a aceptar posibles planes de back-out Ciertos

entornos de produccioacuten pueden elegir ignorar lo problemas que una

nueva versioacuten puede provocar en otras aacutereas y resistirse a volver a la

uacuteltima versioacuten estable

La implementacioacuten sincronizada de versiones en entornos altamente

distribuidos

La solucioacuten a estos problemas pasa por

Un firme compromiso de la organizacioacuten con la Gestioacuten de Versiones y

sus responsables

Un adecuado plan de comunicacioacuten que informe a todos los

responsables y usuarios de la organizacioacuten TI de las ventajas de una

correcta gestioacuten de todo el proceso de cambio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 22

Una versioacuten es un grupo de CIs de nueva creacioacuten o modificados que han sido

validados para su instalacioacuten en el entorno de produccioacuten Las especificaciones

funcionales y teacutecnicas de una versioacuten estaacuten determinadas en la RFC

correspondiente

23 Clasificacioacuten de las Versiones

Las versiones pueden clasificarse seguacuten 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 caracteriacutesticas teacutecnicas etc

Versiones menores que suelen implicar la correccioacuten 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 raacutepida

un error conocido

Como pueden llegar a existir muacuteltiples versiones es conveniente definir una

referencia o coacutedigo que los identifique uniacutevocamente El sistema

universalmente aceptado es

Versiones mayores 10 20 etc

Versiones menores 11 12 13 etc

Versiones de emergencia 111 112 etc

Aunque en algunos casos esta clasificacioacuten se refina auacuten maacutes (vea por

ejemplo en la ayuda la versioacuten de su navegador)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 23

En su ciclo de vida una versioacuten puede encontrase en diversos estados

desarrollo pruebas produccioacuten y archivado11

En la Figura 8 nos ilustra graacuteficamente la evolucioacuten temporal de una versioacuten

Figura 8 Evolucioacuten temporal de una versioacuten

El despliegue de nuevas versiones puede realizarse de diferentes maneras y

es responsabilidad de la Gestioacuten de Cambios el determinar la forma maacutes

conveniente de hacerlo Entre las opciones maacutes habituales cabe contar

Versioacuten delta soacutelo se testean e instalan los elementos modificados

Esta opcioacuten tiene como ventaja su mayor simplicidad pero conlleva el

peligro de que puedan aparecer problemas e incompatibilidades en el

entorno de produccioacuten

Versioacuten completa Se distribuyen todos los elementos afectados ya

hayan sido modificados o no Aunque esta opcioacuten es obviamente maacutes

trabajosa es maacutes improbable que se generen incidentes tras la

instalacioacuten si se han realizado las pruebas pertinentes

11

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 24

Paquete de Versiones La Gestioacuten 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 opcioacuten es obligada por incompatibilidades entre una nueva

versioacuten con software o hardware previamente instalado Pensemos por

ejemplo en la migracioacuten a un nuevo sistema operativo que requiere

hardware maacutes avanzado yo nuevos versiones de los programas

ofimaacuteticos

24 Visioacuten General

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI12

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten de Versiones se resumen

sucintamente en la siguiente Figura 9

12

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 25

Figura 9 Visioacuten General de la Gestioacuten de Versiones

25 Planificacioacuten

Es crucial establecer un marco general para el lanzamiento de nuevas

versiones que fije una metodologiacutea 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

especiacuteficos que tomen en cuenta las peculiaridades de cada caso

A la hora de planificar correctamente el lanzamiento de una nueva versioacuten se

deben de tomar en cuenta los siguientes factores

Coacutemo puede afectar la nueva versioacuten a otras aacutereas del entramado TI

Queacute CIs se veraacuten directa o indirectamente implicados durante y tras el

lanzamiento de la nueva versioacuten

Coacutemo ha de construirse el entorno de pruebas para que eacuteste sea fiel

reflejo del entorno de produccioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 26

Queacute planes de back-out son necesarios

Coacutemo y cuaacutendo se deben implementar los planes de back-out para

minimizar el posible impacto negativo sobre el servicio y la integridad del

sistema TI

Cuaacuteles son los recursos humanos y teacutecnicos necesarios para llevar a

cabo la implementacioacuten de la nueva versioacuten con garantiacuteas de eacutexito

Quieacutenes seraacuten los responsables directos en las diferentes etapas del

proceso

Queacute planes de comunicacioacuten yo formacioacuten deben desarrollarse para

que los usuarios esteacuten puntualmente informados y puedan percibir la

nueva versioacuten como una mejora

Queacute tipo de despliegue es el maacutes adecuado completo delta

sincronizado en todas los emplazamientos gradual

Cuaacutel es la vida media uacutetil esperada de la nueva versioacuten

Queacute impacto puede tener el proceso de lanzamiento de la nueva versioacuten

en la calidad del servicio

Si es posible establecer meacutetricas precisas que determinen el grado de

eacutexito del lanzamiento de la nueva versioacuten

26 Desarrollo

La Gestioacuten de Versiones es la encargada del disentildeo y construccioacuten de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes

A veces el desarrollo se realizara en la casa y muchas otras requeriraacute la

participacioacuten de proveedores externos En este segundo caso la tarea de la

Gestioacuten de Versiones seraacute la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC Asimismo la Gestioacuten de Versiones seraacute la responsable de todo el

proceso de configuracioacuten necesario

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

Parte integrante del desarrollo lo componen los planes de back-out asociados

Estos tendraacuten que tomar en cuenta la disponibilidad acordada con los clientes

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

Es importante que las pruebas incluyan los planes de back-out para

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

Que meacutetricas determinan la puesta en marcha de los planes de back-out

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

informada por el Service Desk de los comentarios quejas incidentes etc que

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

recibidas y que se tomen las medidas correctivas necesarias para minimizar el

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

Es frecuente y a su vez un grave error que cuando se aborden cuestiones de

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

Es inuacutetil disponer de un sofisticado servicio TI si los usuarios debido a una

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

remotos mediante moacutedulos de e-learning sobre el funcionamiento de la

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 16: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 16

satisfactorio se da la aprobacioacuten del cambio y en caso de que el rendimiento

sea malo se pasa a la fase de reingenieriacutea 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 estaacute

probado se da la autorizacioacuten e implementacioacuten ya implementado se ve que no

se hayan tenido desviaciones y se ajusta a las necesidades actuales que

tambieacuten se le considera como revisioacuten post-implementacioacuten

Figura 6 Proceso de control de cambios

175 PROCESO DE MANEJO DE ENTREGAS

Su objetivo es planear y controlar exitosamente la instalacioacuten 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 transicioacuten que se da de acuerdo

a los ambientes por los que se va dando la evolucioacuten del proyecto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 17

En lo que respecta al ambiente de desarrollo vemos en la Figura 7 que se tiene

que hacer la liberacioacuten de las poliacuteticas la liberacioacuten de la planeacioacuten el disentildeo

loacutegico de la infraestructura que se va a implementar y la adquisicioacuten de

software y hardware estaacuten 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 construccioacuten y

liberacioacuten de las configuraciones (nivel loacutegico) se hacen las pruebas para

establecer los acuerdos de aceptacioacuten se da la aceptacioacuten total de versiones y

de modelos se arranca la planeacioacuten y finalmente las pruebas y

comunicaciones y en lo que es el ambiente real vemos que se da la

distribucioacuten e instalacioacuten 10

En la etapa del ambiente real es la que se ve de forma maacutes concreta ya que

muchas veces no tenemos idea de todo lo que pasa hasta antes de la

instalacioacuten

En el proceso de entrega del servicio es el punto en el que el usuario hace uno

del servicio y no sabe que detraacutes del servicio que estaacute 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 maacutes 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 planeacioacuten monitoreo anaacutelisis y por un sin fin de pruebas con la intencioacuten

de que en caso de que algo no funcione se deacute en la fase de pruebas

controladas y no en la fase de pruebas en ambiente real donde el mayor

afectado es el cliente

10

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 18

Figura 7 Proceso de manejo de entregas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 19

CAPITULO II

GESTION DE VERSIONES

21 Introduccioacuten y Objetivos

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten 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 implementacioacuten de cualquier

cambio

La Gestioacuten de Cambios es la encargada de aprobar y supervisar todo el

proceso pero es tarea especiacutefica de la Gestioacuten de Versiones el disentildear poner a

prueba e instalar en el entorno de produccioacuten los cambios preestablecidos

Todo ello requiere de una cuidadosa planificacioacuten y coordinacioacuten con el resto

de procesos asociados a la Gestioacuten de Servicios TI

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 20

Entre los principales objetivos de la Gestioacuten de Versiones se incluyen

Establecer una poliacutetica de implementacioacuten de nuevas versiones de

hardware y software

Implementar las nuevas versiones de software y hardware en el entorno

de produccioacuten tras su verificacioacuten en un entorno realista de pruebas

Garantizar que el proceso de cambio cumpla las especificaciones de la

RFC correspondiente

Asegurar en colaboracioacuten con la Gestioacuten de Cambios y

Configuraciones que todos los cambios se ven correctamente reflejados

en la CMDB

Archivar copias ideacutenticas del software en produccioacuten asiacute como de toda

su documentacioacuten asociada en la Biblioteca de Software Definitivo

(DSL)

Mantener actualizado el Depoacutesito de Hardware Definitivo (DHS)

22 Beneficios y Dificultades

Los beneficios de una correcta Gestioacuten 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 nuacutemero de incidentes por incompatibilidades con otro

software o hardware instalado

El proceso de pruebas asociado no soacutelo permite asegurar la calidad del

software y hardware a instalar sino que tambieacuten permite conocer la

opinioacuten 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 nuacutemero de copias de software ilegales

Control centralizado del software y hardware desplegado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 21

Proteccioacuten contra virus y problemas asociados a versiones de software

incontroladas

Las principales dificultades con las que topa la Gestioacuten de Versiones son

No existe una clara asignacioacuten de responsabilidades yo la organizacioacuten

TI no acepta la figura dominante de la Gestioacuten de Versiones en todo el

proceso de implementacioacuten 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 centralizacioacuten del

proceso de cambio Es habitual que existan reticencias a adoptar

sistemas estandarizados en toda la organizacioacuten sobre todo cuando

eacutesta no ha sido la poliacutetica tradicional de la misma

Se realizan cambios sin tener en cuenta a la Gestioacuten de Versiones

argumentado que estos soacutelo son responsabilidad de un determinado

grupo de trabajo o que su urgencia requeriacutea de ello

Hay resistencias a aceptar posibles planes de back-out Ciertos

entornos de produccioacuten pueden elegir ignorar lo problemas que una

nueva versioacuten puede provocar en otras aacutereas y resistirse a volver a la

uacuteltima versioacuten estable

La implementacioacuten sincronizada de versiones en entornos altamente

distribuidos

La solucioacuten a estos problemas pasa por

Un firme compromiso de la organizacioacuten con la Gestioacuten de Versiones y

sus responsables

Un adecuado plan de comunicacioacuten que informe a todos los

responsables y usuarios de la organizacioacuten TI de las ventajas de una

correcta gestioacuten de todo el proceso de cambio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 22

Una versioacuten es un grupo de CIs de nueva creacioacuten o modificados que han sido

validados para su instalacioacuten en el entorno de produccioacuten Las especificaciones

funcionales y teacutecnicas de una versioacuten estaacuten determinadas en la RFC

correspondiente

23 Clasificacioacuten de las Versiones

Las versiones pueden clasificarse seguacuten 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 caracteriacutesticas teacutecnicas etc

Versiones menores que suelen implicar la correccioacuten 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 raacutepida

un error conocido

Como pueden llegar a existir muacuteltiples versiones es conveniente definir una

referencia o coacutedigo que los identifique uniacutevocamente El sistema

universalmente aceptado es

Versiones mayores 10 20 etc

Versiones menores 11 12 13 etc

Versiones de emergencia 111 112 etc

Aunque en algunos casos esta clasificacioacuten se refina auacuten maacutes (vea por

ejemplo en la ayuda la versioacuten de su navegador)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 23

En su ciclo de vida una versioacuten puede encontrase en diversos estados

desarrollo pruebas produccioacuten y archivado11

En la Figura 8 nos ilustra graacuteficamente la evolucioacuten temporal de una versioacuten

Figura 8 Evolucioacuten temporal de una versioacuten

El despliegue de nuevas versiones puede realizarse de diferentes maneras y

es responsabilidad de la Gestioacuten de Cambios el determinar la forma maacutes

conveniente de hacerlo Entre las opciones maacutes habituales cabe contar

Versioacuten delta soacutelo se testean e instalan los elementos modificados

Esta opcioacuten tiene como ventaja su mayor simplicidad pero conlleva el

peligro de que puedan aparecer problemas e incompatibilidades en el

entorno de produccioacuten

Versioacuten completa Se distribuyen todos los elementos afectados ya

hayan sido modificados o no Aunque esta opcioacuten es obviamente maacutes

trabajosa es maacutes improbable que se generen incidentes tras la

instalacioacuten si se han realizado las pruebas pertinentes

11

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 24

Paquete de Versiones La Gestioacuten 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 opcioacuten es obligada por incompatibilidades entre una nueva

versioacuten con software o hardware previamente instalado Pensemos por

ejemplo en la migracioacuten a un nuevo sistema operativo que requiere

hardware maacutes avanzado yo nuevos versiones de los programas

ofimaacuteticos

24 Visioacuten General

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI12

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten de Versiones se resumen

sucintamente en la siguiente Figura 9

12

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 25

Figura 9 Visioacuten General de la Gestioacuten de Versiones

25 Planificacioacuten

Es crucial establecer un marco general para el lanzamiento de nuevas

versiones que fije una metodologiacutea 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

especiacuteficos que tomen en cuenta las peculiaridades de cada caso

A la hora de planificar correctamente el lanzamiento de una nueva versioacuten se

deben de tomar en cuenta los siguientes factores

Coacutemo puede afectar la nueva versioacuten a otras aacutereas del entramado TI

Queacute CIs se veraacuten directa o indirectamente implicados durante y tras el

lanzamiento de la nueva versioacuten

Coacutemo ha de construirse el entorno de pruebas para que eacuteste sea fiel

reflejo del entorno de produccioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 26

Queacute planes de back-out son necesarios

Coacutemo y cuaacutendo se deben implementar los planes de back-out para

minimizar el posible impacto negativo sobre el servicio y la integridad del

sistema TI

Cuaacuteles son los recursos humanos y teacutecnicos necesarios para llevar a

cabo la implementacioacuten de la nueva versioacuten con garantiacuteas de eacutexito

Quieacutenes seraacuten los responsables directos en las diferentes etapas del

proceso

Queacute planes de comunicacioacuten yo formacioacuten deben desarrollarse para

que los usuarios esteacuten puntualmente informados y puedan percibir la

nueva versioacuten como una mejora

Queacute tipo de despliegue es el maacutes adecuado completo delta

sincronizado en todas los emplazamientos gradual

Cuaacutel es la vida media uacutetil esperada de la nueva versioacuten

Queacute impacto puede tener el proceso de lanzamiento de la nueva versioacuten

en la calidad del servicio

Si es posible establecer meacutetricas precisas que determinen el grado de

eacutexito del lanzamiento de la nueva versioacuten

26 Desarrollo

La Gestioacuten de Versiones es la encargada del disentildeo y construccioacuten de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes

A veces el desarrollo se realizara en la casa y muchas otras requeriraacute la

participacioacuten de proveedores externos En este segundo caso la tarea de la

Gestioacuten de Versiones seraacute la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC Asimismo la Gestioacuten de Versiones seraacute la responsable de todo el

proceso de configuracioacuten necesario

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

Parte integrante del desarrollo lo componen los planes de back-out asociados

Estos tendraacuten que tomar en cuenta la disponibilidad acordada con los clientes

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

Es importante que las pruebas incluyan los planes de back-out para

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

Que meacutetricas determinan la puesta en marcha de los planes de back-out

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

informada por el Service Desk de los comentarios quejas incidentes etc que

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

recibidas y que se tomen las medidas correctivas necesarias para minimizar el

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

Es frecuente y a su vez un grave error que cuando se aborden cuestiones de

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

Es inuacutetil disponer de un sofisticado servicio TI si los usuarios debido a una

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

remotos mediante moacutedulos de e-learning sobre el funcionamiento de la

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 17: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 17

En lo que respecta al ambiente de desarrollo vemos en la Figura 7 que se tiene

que hacer la liberacioacuten de las poliacuteticas la liberacioacuten de la planeacioacuten el disentildeo

loacutegico de la infraestructura que se va a implementar y la adquisicioacuten de

software y hardware estaacuten 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 construccioacuten y

liberacioacuten de las configuraciones (nivel loacutegico) se hacen las pruebas para

establecer los acuerdos de aceptacioacuten se da la aceptacioacuten total de versiones y

de modelos se arranca la planeacioacuten y finalmente las pruebas y

comunicaciones y en lo que es el ambiente real vemos que se da la

distribucioacuten e instalacioacuten 10

En la etapa del ambiente real es la que se ve de forma maacutes concreta ya que

muchas veces no tenemos idea de todo lo que pasa hasta antes de la

instalacioacuten

En el proceso de entrega del servicio es el punto en el que el usuario hace uno

del servicio y no sabe que detraacutes del servicio que estaacute 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 maacutes 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 planeacioacuten monitoreo anaacutelisis y por un sin fin de pruebas con la intencioacuten

de que en caso de que algo no funcione se deacute en la fase de pruebas

controladas y no en la fase de pruebas en ambiente real donde el mayor

afectado es el cliente

10

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-itilshtmlproceso

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 18

Figura 7 Proceso de manejo de entregas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 19

CAPITULO II

GESTION DE VERSIONES

21 Introduccioacuten y Objetivos

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten 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 implementacioacuten de cualquier

cambio

La Gestioacuten de Cambios es la encargada de aprobar y supervisar todo el

proceso pero es tarea especiacutefica de la Gestioacuten de Versiones el disentildear poner a

prueba e instalar en el entorno de produccioacuten los cambios preestablecidos

Todo ello requiere de una cuidadosa planificacioacuten y coordinacioacuten con el resto

de procesos asociados a la Gestioacuten de Servicios TI

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 20

Entre los principales objetivos de la Gestioacuten de Versiones se incluyen

Establecer una poliacutetica de implementacioacuten de nuevas versiones de

hardware y software

Implementar las nuevas versiones de software y hardware en el entorno

de produccioacuten tras su verificacioacuten en un entorno realista de pruebas

Garantizar que el proceso de cambio cumpla las especificaciones de la

RFC correspondiente

Asegurar en colaboracioacuten con la Gestioacuten de Cambios y

Configuraciones que todos los cambios se ven correctamente reflejados

en la CMDB

Archivar copias ideacutenticas del software en produccioacuten asiacute como de toda

su documentacioacuten asociada en la Biblioteca de Software Definitivo

(DSL)

Mantener actualizado el Depoacutesito de Hardware Definitivo (DHS)

22 Beneficios y Dificultades

Los beneficios de una correcta Gestioacuten 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 nuacutemero de incidentes por incompatibilidades con otro

software o hardware instalado

El proceso de pruebas asociado no soacutelo permite asegurar la calidad del

software y hardware a instalar sino que tambieacuten permite conocer la

opinioacuten 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 nuacutemero de copias de software ilegales

Control centralizado del software y hardware desplegado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 21

Proteccioacuten contra virus y problemas asociados a versiones de software

incontroladas

Las principales dificultades con las que topa la Gestioacuten de Versiones son

No existe una clara asignacioacuten de responsabilidades yo la organizacioacuten

TI no acepta la figura dominante de la Gestioacuten de Versiones en todo el

proceso de implementacioacuten 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 centralizacioacuten del

proceso de cambio Es habitual que existan reticencias a adoptar

sistemas estandarizados en toda la organizacioacuten sobre todo cuando

eacutesta no ha sido la poliacutetica tradicional de la misma

Se realizan cambios sin tener en cuenta a la Gestioacuten de Versiones

argumentado que estos soacutelo son responsabilidad de un determinado

grupo de trabajo o que su urgencia requeriacutea de ello

Hay resistencias a aceptar posibles planes de back-out Ciertos

entornos de produccioacuten pueden elegir ignorar lo problemas que una

nueva versioacuten puede provocar en otras aacutereas y resistirse a volver a la

uacuteltima versioacuten estable

La implementacioacuten sincronizada de versiones en entornos altamente

distribuidos

La solucioacuten a estos problemas pasa por

Un firme compromiso de la organizacioacuten con la Gestioacuten de Versiones y

sus responsables

Un adecuado plan de comunicacioacuten que informe a todos los

responsables y usuarios de la organizacioacuten TI de las ventajas de una

correcta gestioacuten de todo el proceso de cambio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 22

Una versioacuten es un grupo de CIs de nueva creacioacuten o modificados que han sido

validados para su instalacioacuten en el entorno de produccioacuten Las especificaciones

funcionales y teacutecnicas de una versioacuten estaacuten determinadas en la RFC

correspondiente

23 Clasificacioacuten de las Versiones

Las versiones pueden clasificarse seguacuten 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 caracteriacutesticas teacutecnicas etc

Versiones menores que suelen implicar la correccioacuten 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 raacutepida

un error conocido

Como pueden llegar a existir muacuteltiples versiones es conveniente definir una

referencia o coacutedigo que los identifique uniacutevocamente El sistema

universalmente aceptado es

Versiones mayores 10 20 etc

Versiones menores 11 12 13 etc

Versiones de emergencia 111 112 etc

Aunque en algunos casos esta clasificacioacuten se refina auacuten maacutes (vea por

ejemplo en la ayuda la versioacuten de su navegador)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 23

En su ciclo de vida una versioacuten puede encontrase en diversos estados

desarrollo pruebas produccioacuten y archivado11

En la Figura 8 nos ilustra graacuteficamente la evolucioacuten temporal de una versioacuten

Figura 8 Evolucioacuten temporal de una versioacuten

El despliegue de nuevas versiones puede realizarse de diferentes maneras y

es responsabilidad de la Gestioacuten de Cambios el determinar la forma maacutes

conveniente de hacerlo Entre las opciones maacutes habituales cabe contar

Versioacuten delta soacutelo se testean e instalan los elementos modificados

Esta opcioacuten tiene como ventaja su mayor simplicidad pero conlleva el

peligro de que puedan aparecer problemas e incompatibilidades en el

entorno de produccioacuten

Versioacuten completa Se distribuyen todos los elementos afectados ya

hayan sido modificados o no Aunque esta opcioacuten es obviamente maacutes

trabajosa es maacutes improbable que se generen incidentes tras la

instalacioacuten si se han realizado las pruebas pertinentes

11

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 24

Paquete de Versiones La Gestioacuten 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 opcioacuten es obligada por incompatibilidades entre una nueva

versioacuten con software o hardware previamente instalado Pensemos por

ejemplo en la migracioacuten a un nuevo sistema operativo que requiere

hardware maacutes avanzado yo nuevos versiones de los programas

ofimaacuteticos

24 Visioacuten General

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI12

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten de Versiones se resumen

sucintamente en la siguiente Figura 9

12

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 25

Figura 9 Visioacuten General de la Gestioacuten de Versiones

25 Planificacioacuten

Es crucial establecer un marco general para el lanzamiento de nuevas

versiones que fije una metodologiacutea 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

especiacuteficos que tomen en cuenta las peculiaridades de cada caso

A la hora de planificar correctamente el lanzamiento de una nueva versioacuten se

deben de tomar en cuenta los siguientes factores

Coacutemo puede afectar la nueva versioacuten a otras aacutereas del entramado TI

Queacute CIs se veraacuten directa o indirectamente implicados durante y tras el

lanzamiento de la nueva versioacuten

Coacutemo ha de construirse el entorno de pruebas para que eacuteste sea fiel

reflejo del entorno de produccioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 26

Queacute planes de back-out son necesarios

Coacutemo y cuaacutendo se deben implementar los planes de back-out para

minimizar el posible impacto negativo sobre el servicio y la integridad del

sistema TI

Cuaacuteles son los recursos humanos y teacutecnicos necesarios para llevar a

cabo la implementacioacuten de la nueva versioacuten con garantiacuteas de eacutexito

Quieacutenes seraacuten los responsables directos en las diferentes etapas del

proceso

Queacute planes de comunicacioacuten yo formacioacuten deben desarrollarse para

que los usuarios esteacuten puntualmente informados y puedan percibir la

nueva versioacuten como una mejora

Queacute tipo de despliegue es el maacutes adecuado completo delta

sincronizado en todas los emplazamientos gradual

Cuaacutel es la vida media uacutetil esperada de la nueva versioacuten

Queacute impacto puede tener el proceso de lanzamiento de la nueva versioacuten

en la calidad del servicio

Si es posible establecer meacutetricas precisas que determinen el grado de

eacutexito del lanzamiento de la nueva versioacuten

26 Desarrollo

La Gestioacuten de Versiones es la encargada del disentildeo y construccioacuten de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes

A veces el desarrollo se realizara en la casa y muchas otras requeriraacute la

participacioacuten de proveedores externos En este segundo caso la tarea de la

Gestioacuten de Versiones seraacute la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC Asimismo la Gestioacuten de Versiones seraacute la responsable de todo el

proceso de configuracioacuten necesario

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

Parte integrante del desarrollo lo componen los planes de back-out asociados

Estos tendraacuten que tomar en cuenta la disponibilidad acordada con los clientes

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

Es importante que las pruebas incluyan los planes de back-out para

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

Que meacutetricas determinan la puesta en marcha de los planes de back-out

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

informada por el Service Desk de los comentarios quejas incidentes etc que

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

recibidas y que se tomen las medidas correctivas necesarias para minimizar el

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

Es frecuente y a su vez un grave error que cuando se aborden cuestiones de

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

Es inuacutetil disponer de un sofisticado servicio TI si los usuarios debido a una

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

remotos mediante moacutedulos de e-learning sobre el funcionamiento de la

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 18: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 18

Figura 7 Proceso de manejo de entregas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 19

CAPITULO II

GESTION DE VERSIONES

21 Introduccioacuten y Objetivos

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten 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 implementacioacuten de cualquier

cambio

La Gestioacuten de Cambios es la encargada de aprobar y supervisar todo el

proceso pero es tarea especiacutefica de la Gestioacuten de Versiones el disentildear poner a

prueba e instalar en el entorno de produccioacuten los cambios preestablecidos

Todo ello requiere de una cuidadosa planificacioacuten y coordinacioacuten con el resto

de procesos asociados a la Gestioacuten de Servicios TI

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 20

Entre los principales objetivos de la Gestioacuten de Versiones se incluyen

Establecer una poliacutetica de implementacioacuten de nuevas versiones de

hardware y software

Implementar las nuevas versiones de software y hardware en el entorno

de produccioacuten tras su verificacioacuten en un entorno realista de pruebas

Garantizar que el proceso de cambio cumpla las especificaciones de la

RFC correspondiente

Asegurar en colaboracioacuten con la Gestioacuten de Cambios y

Configuraciones que todos los cambios se ven correctamente reflejados

en la CMDB

Archivar copias ideacutenticas del software en produccioacuten asiacute como de toda

su documentacioacuten asociada en la Biblioteca de Software Definitivo

(DSL)

Mantener actualizado el Depoacutesito de Hardware Definitivo (DHS)

22 Beneficios y Dificultades

Los beneficios de una correcta Gestioacuten 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 nuacutemero de incidentes por incompatibilidades con otro

software o hardware instalado

El proceso de pruebas asociado no soacutelo permite asegurar la calidad del

software y hardware a instalar sino que tambieacuten permite conocer la

opinioacuten 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 nuacutemero de copias de software ilegales

Control centralizado del software y hardware desplegado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 21

Proteccioacuten contra virus y problemas asociados a versiones de software

incontroladas

Las principales dificultades con las que topa la Gestioacuten de Versiones son

No existe una clara asignacioacuten de responsabilidades yo la organizacioacuten

TI no acepta la figura dominante de la Gestioacuten de Versiones en todo el

proceso de implementacioacuten 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 centralizacioacuten del

proceso de cambio Es habitual que existan reticencias a adoptar

sistemas estandarizados en toda la organizacioacuten sobre todo cuando

eacutesta no ha sido la poliacutetica tradicional de la misma

Se realizan cambios sin tener en cuenta a la Gestioacuten de Versiones

argumentado que estos soacutelo son responsabilidad de un determinado

grupo de trabajo o que su urgencia requeriacutea de ello

Hay resistencias a aceptar posibles planes de back-out Ciertos

entornos de produccioacuten pueden elegir ignorar lo problemas que una

nueva versioacuten puede provocar en otras aacutereas y resistirse a volver a la

uacuteltima versioacuten estable

La implementacioacuten sincronizada de versiones en entornos altamente

distribuidos

La solucioacuten a estos problemas pasa por

Un firme compromiso de la organizacioacuten con la Gestioacuten de Versiones y

sus responsables

Un adecuado plan de comunicacioacuten que informe a todos los

responsables y usuarios de la organizacioacuten TI de las ventajas de una

correcta gestioacuten de todo el proceso de cambio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 22

Una versioacuten es un grupo de CIs de nueva creacioacuten o modificados que han sido

validados para su instalacioacuten en el entorno de produccioacuten Las especificaciones

funcionales y teacutecnicas de una versioacuten estaacuten determinadas en la RFC

correspondiente

23 Clasificacioacuten de las Versiones

Las versiones pueden clasificarse seguacuten 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 caracteriacutesticas teacutecnicas etc

Versiones menores que suelen implicar la correccioacuten 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 raacutepida

un error conocido

Como pueden llegar a existir muacuteltiples versiones es conveniente definir una

referencia o coacutedigo que los identifique uniacutevocamente El sistema

universalmente aceptado es

Versiones mayores 10 20 etc

Versiones menores 11 12 13 etc

Versiones de emergencia 111 112 etc

Aunque en algunos casos esta clasificacioacuten se refina auacuten maacutes (vea por

ejemplo en la ayuda la versioacuten de su navegador)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 23

En su ciclo de vida una versioacuten puede encontrase en diversos estados

desarrollo pruebas produccioacuten y archivado11

En la Figura 8 nos ilustra graacuteficamente la evolucioacuten temporal de una versioacuten

Figura 8 Evolucioacuten temporal de una versioacuten

El despliegue de nuevas versiones puede realizarse de diferentes maneras y

es responsabilidad de la Gestioacuten de Cambios el determinar la forma maacutes

conveniente de hacerlo Entre las opciones maacutes habituales cabe contar

Versioacuten delta soacutelo se testean e instalan los elementos modificados

Esta opcioacuten tiene como ventaja su mayor simplicidad pero conlleva el

peligro de que puedan aparecer problemas e incompatibilidades en el

entorno de produccioacuten

Versioacuten completa Se distribuyen todos los elementos afectados ya

hayan sido modificados o no Aunque esta opcioacuten es obviamente maacutes

trabajosa es maacutes improbable que se generen incidentes tras la

instalacioacuten si se han realizado las pruebas pertinentes

11

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 24

Paquete de Versiones La Gestioacuten 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 opcioacuten es obligada por incompatibilidades entre una nueva

versioacuten con software o hardware previamente instalado Pensemos por

ejemplo en la migracioacuten a un nuevo sistema operativo que requiere

hardware maacutes avanzado yo nuevos versiones de los programas

ofimaacuteticos

24 Visioacuten General

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI12

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten de Versiones se resumen

sucintamente en la siguiente Figura 9

12

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 25

Figura 9 Visioacuten General de la Gestioacuten de Versiones

25 Planificacioacuten

Es crucial establecer un marco general para el lanzamiento de nuevas

versiones que fije una metodologiacutea 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

especiacuteficos que tomen en cuenta las peculiaridades de cada caso

A la hora de planificar correctamente el lanzamiento de una nueva versioacuten se

deben de tomar en cuenta los siguientes factores

Coacutemo puede afectar la nueva versioacuten a otras aacutereas del entramado TI

Queacute CIs se veraacuten directa o indirectamente implicados durante y tras el

lanzamiento de la nueva versioacuten

Coacutemo ha de construirse el entorno de pruebas para que eacuteste sea fiel

reflejo del entorno de produccioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 26

Queacute planes de back-out son necesarios

Coacutemo y cuaacutendo se deben implementar los planes de back-out para

minimizar el posible impacto negativo sobre el servicio y la integridad del

sistema TI

Cuaacuteles son los recursos humanos y teacutecnicos necesarios para llevar a

cabo la implementacioacuten de la nueva versioacuten con garantiacuteas de eacutexito

Quieacutenes seraacuten los responsables directos en las diferentes etapas del

proceso

Queacute planes de comunicacioacuten yo formacioacuten deben desarrollarse para

que los usuarios esteacuten puntualmente informados y puedan percibir la

nueva versioacuten como una mejora

Queacute tipo de despliegue es el maacutes adecuado completo delta

sincronizado en todas los emplazamientos gradual

Cuaacutel es la vida media uacutetil esperada de la nueva versioacuten

Queacute impacto puede tener el proceso de lanzamiento de la nueva versioacuten

en la calidad del servicio

Si es posible establecer meacutetricas precisas que determinen el grado de

eacutexito del lanzamiento de la nueva versioacuten

26 Desarrollo

La Gestioacuten de Versiones es la encargada del disentildeo y construccioacuten de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes

A veces el desarrollo se realizara en la casa y muchas otras requeriraacute la

participacioacuten de proveedores externos En este segundo caso la tarea de la

Gestioacuten de Versiones seraacute la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC Asimismo la Gestioacuten de Versiones seraacute la responsable de todo el

proceso de configuracioacuten necesario

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

Parte integrante del desarrollo lo componen los planes de back-out asociados

Estos tendraacuten que tomar en cuenta la disponibilidad acordada con los clientes

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

Es importante que las pruebas incluyan los planes de back-out para

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

Que meacutetricas determinan la puesta en marcha de los planes de back-out

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

informada por el Service Desk de los comentarios quejas incidentes etc que

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

recibidas y que se tomen las medidas correctivas necesarias para minimizar el

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

Es frecuente y a su vez un grave error que cuando se aborden cuestiones de

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

Es inuacutetil disponer de un sofisticado servicio TI si los usuarios debido a una

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

remotos mediante moacutedulos de e-learning sobre el funcionamiento de la

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 19: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 19

CAPITULO II

GESTION DE VERSIONES

21 Introduccioacuten y Objetivos

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten 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 implementacioacuten de cualquier

cambio

La Gestioacuten de Cambios es la encargada de aprobar y supervisar todo el

proceso pero es tarea especiacutefica de la Gestioacuten de Versiones el disentildear poner a

prueba e instalar en el entorno de produccioacuten los cambios preestablecidos

Todo ello requiere de una cuidadosa planificacioacuten y coordinacioacuten con el resto

de procesos asociados a la Gestioacuten de Servicios TI

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 20

Entre los principales objetivos de la Gestioacuten de Versiones se incluyen

Establecer una poliacutetica de implementacioacuten de nuevas versiones de

hardware y software

Implementar las nuevas versiones de software y hardware en el entorno

de produccioacuten tras su verificacioacuten en un entorno realista de pruebas

Garantizar que el proceso de cambio cumpla las especificaciones de la

RFC correspondiente

Asegurar en colaboracioacuten con la Gestioacuten de Cambios y

Configuraciones que todos los cambios se ven correctamente reflejados

en la CMDB

Archivar copias ideacutenticas del software en produccioacuten asiacute como de toda

su documentacioacuten asociada en la Biblioteca de Software Definitivo

(DSL)

Mantener actualizado el Depoacutesito de Hardware Definitivo (DHS)

22 Beneficios y Dificultades

Los beneficios de una correcta Gestioacuten 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 nuacutemero de incidentes por incompatibilidades con otro

software o hardware instalado

El proceso de pruebas asociado no soacutelo permite asegurar la calidad del

software y hardware a instalar sino que tambieacuten permite conocer la

opinioacuten 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 nuacutemero de copias de software ilegales

Control centralizado del software y hardware desplegado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 21

Proteccioacuten contra virus y problemas asociados a versiones de software

incontroladas

Las principales dificultades con las que topa la Gestioacuten de Versiones son

No existe una clara asignacioacuten de responsabilidades yo la organizacioacuten

TI no acepta la figura dominante de la Gestioacuten de Versiones en todo el

proceso de implementacioacuten 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 centralizacioacuten del

proceso de cambio Es habitual que existan reticencias a adoptar

sistemas estandarizados en toda la organizacioacuten sobre todo cuando

eacutesta no ha sido la poliacutetica tradicional de la misma

Se realizan cambios sin tener en cuenta a la Gestioacuten de Versiones

argumentado que estos soacutelo son responsabilidad de un determinado

grupo de trabajo o que su urgencia requeriacutea de ello

Hay resistencias a aceptar posibles planes de back-out Ciertos

entornos de produccioacuten pueden elegir ignorar lo problemas que una

nueva versioacuten puede provocar en otras aacutereas y resistirse a volver a la

uacuteltima versioacuten estable

La implementacioacuten sincronizada de versiones en entornos altamente

distribuidos

La solucioacuten a estos problemas pasa por

Un firme compromiso de la organizacioacuten con la Gestioacuten de Versiones y

sus responsables

Un adecuado plan de comunicacioacuten que informe a todos los

responsables y usuarios de la organizacioacuten TI de las ventajas de una

correcta gestioacuten de todo el proceso de cambio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 22

Una versioacuten es un grupo de CIs de nueva creacioacuten o modificados que han sido

validados para su instalacioacuten en el entorno de produccioacuten Las especificaciones

funcionales y teacutecnicas de una versioacuten estaacuten determinadas en la RFC

correspondiente

23 Clasificacioacuten de las Versiones

Las versiones pueden clasificarse seguacuten 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 caracteriacutesticas teacutecnicas etc

Versiones menores que suelen implicar la correccioacuten 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 raacutepida

un error conocido

Como pueden llegar a existir muacuteltiples versiones es conveniente definir una

referencia o coacutedigo que los identifique uniacutevocamente El sistema

universalmente aceptado es

Versiones mayores 10 20 etc

Versiones menores 11 12 13 etc

Versiones de emergencia 111 112 etc

Aunque en algunos casos esta clasificacioacuten se refina auacuten maacutes (vea por

ejemplo en la ayuda la versioacuten de su navegador)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 23

En su ciclo de vida una versioacuten puede encontrase en diversos estados

desarrollo pruebas produccioacuten y archivado11

En la Figura 8 nos ilustra graacuteficamente la evolucioacuten temporal de una versioacuten

Figura 8 Evolucioacuten temporal de una versioacuten

El despliegue de nuevas versiones puede realizarse de diferentes maneras y

es responsabilidad de la Gestioacuten de Cambios el determinar la forma maacutes

conveniente de hacerlo Entre las opciones maacutes habituales cabe contar

Versioacuten delta soacutelo se testean e instalan los elementos modificados

Esta opcioacuten tiene como ventaja su mayor simplicidad pero conlleva el

peligro de que puedan aparecer problemas e incompatibilidades en el

entorno de produccioacuten

Versioacuten completa Se distribuyen todos los elementos afectados ya

hayan sido modificados o no Aunque esta opcioacuten es obviamente maacutes

trabajosa es maacutes improbable que se generen incidentes tras la

instalacioacuten si se han realizado las pruebas pertinentes

11

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 24

Paquete de Versiones La Gestioacuten 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 opcioacuten es obligada por incompatibilidades entre una nueva

versioacuten con software o hardware previamente instalado Pensemos por

ejemplo en la migracioacuten a un nuevo sistema operativo que requiere

hardware maacutes avanzado yo nuevos versiones de los programas

ofimaacuteticos

24 Visioacuten General

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI12

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten de Versiones se resumen

sucintamente en la siguiente Figura 9

12

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 25

Figura 9 Visioacuten General de la Gestioacuten de Versiones

25 Planificacioacuten

Es crucial establecer un marco general para el lanzamiento de nuevas

versiones que fije una metodologiacutea 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

especiacuteficos que tomen en cuenta las peculiaridades de cada caso

A la hora de planificar correctamente el lanzamiento de una nueva versioacuten se

deben de tomar en cuenta los siguientes factores

Coacutemo puede afectar la nueva versioacuten a otras aacutereas del entramado TI

Queacute CIs se veraacuten directa o indirectamente implicados durante y tras el

lanzamiento de la nueva versioacuten

Coacutemo ha de construirse el entorno de pruebas para que eacuteste sea fiel

reflejo del entorno de produccioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 26

Queacute planes de back-out son necesarios

Coacutemo y cuaacutendo se deben implementar los planes de back-out para

minimizar el posible impacto negativo sobre el servicio y la integridad del

sistema TI

Cuaacuteles son los recursos humanos y teacutecnicos necesarios para llevar a

cabo la implementacioacuten de la nueva versioacuten con garantiacuteas de eacutexito

Quieacutenes seraacuten los responsables directos en las diferentes etapas del

proceso

Queacute planes de comunicacioacuten yo formacioacuten deben desarrollarse para

que los usuarios esteacuten puntualmente informados y puedan percibir la

nueva versioacuten como una mejora

Queacute tipo de despliegue es el maacutes adecuado completo delta

sincronizado en todas los emplazamientos gradual

Cuaacutel es la vida media uacutetil esperada de la nueva versioacuten

Queacute impacto puede tener el proceso de lanzamiento de la nueva versioacuten

en la calidad del servicio

Si es posible establecer meacutetricas precisas que determinen el grado de

eacutexito del lanzamiento de la nueva versioacuten

26 Desarrollo

La Gestioacuten de Versiones es la encargada del disentildeo y construccioacuten de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes

A veces el desarrollo se realizara en la casa y muchas otras requeriraacute la

participacioacuten de proveedores externos En este segundo caso la tarea de la

Gestioacuten de Versiones seraacute la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC Asimismo la Gestioacuten de Versiones seraacute la responsable de todo el

proceso de configuracioacuten necesario

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

Parte integrante del desarrollo lo componen los planes de back-out asociados

Estos tendraacuten que tomar en cuenta la disponibilidad acordada con los clientes

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

Es importante que las pruebas incluyan los planes de back-out para

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

Que meacutetricas determinan la puesta en marcha de los planes de back-out

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

informada por el Service Desk de los comentarios quejas incidentes etc que

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

recibidas y que se tomen las medidas correctivas necesarias para minimizar el

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

Es frecuente y a su vez un grave error que cuando se aborden cuestiones de

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

Es inuacutetil disponer de un sofisticado servicio TI si los usuarios debido a una

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

remotos mediante moacutedulos de e-learning sobre el funcionamiento de la

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 20: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 20

Entre los principales objetivos de la Gestioacuten de Versiones se incluyen

Establecer una poliacutetica de implementacioacuten de nuevas versiones de

hardware y software

Implementar las nuevas versiones de software y hardware en el entorno

de produccioacuten tras su verificacioacuten en un entorno realista de pruebas

Garantizar que el proceso de cambio cumpla las especificaciones de la

RFC correspondiente

Asegurar en colaboracioacuten con la Gestioacuten de Cambios y

Configuraciones que todos los cambios se ven correctamente reflejados

en la CMDB

Archivar copias ideacutenticas del software en produccioacuten asiacute como de toda

su documentacioacuten asociada en la Biblioteca de Software Definitivo

(DSL)

Mantener actualizado el Depoacutesito de Hardware Definitivo (DHS)

22 Beneficios y Dificultades

Los beneficios de una correcta Gestioacuten 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 nuacutemero de incidentes por incompatibilidades con otro

software o hardware instalado

El proceso de pruebas asociado no soacutelo permite asegurar la calidad del

software y hardware a instalar sino que tambieacuten permite conocer la

opinioacuten 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 nuacutemero de copias de software ilegales

Control centralizado del software y hardware desplegado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 21

Proteccioacuten contra virus y problemas asociados a versiones de software

incontroladas

Las principales dificultades con las que topa la Gestioacuten de Versiones son

No existe una clara asignacioacuten de responsabilidades yo la organizacioacuten

TI no acepta la figura dominante de la Gestioacuten de Versiones en todo el

proceso de implementacioacuten 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 centralizacioacuten del

proceso de cambio Es habitual que existan reticencias a adoptar

sistemas estandarizados en toda la organizacioacuten sobre todo cuando

eacutesta no ha sido la poliacutetica tradicional de la misma

Se realizan cambios sin tener en cuenta a la Gestioacuten de Versiones

argumentado que estos soacutelo son responsabilidad de un determinado

grupo de trabajo o que su urgencia requeriacutea de ello

Hay resistencias a aceptar posibles planes de back-out Ciertos

entornos de produccioacuten pueden elegir ignorar lo problemas que una

nueva versioacuten puede provocar en otras aacutereas y resistirse a volver a la

uacuteltima versioacuten estable

La implementacioacuten sincronizada de versiones en entornos altamente

distribuidos

La solucioacuten a estos problemas pasa por

Un firme compromiso de la organizacioacuten con la Gestioacuten de Versiones y

sus responsables

Un adecuado plan de comunicacioacuten que informe a todos los

responsables y usuarios de la organizacioacuten TI de las ventajas de una

correcta gestioacuten de todo el proceso de cambio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 22

Una versioacuten es un grupo de CIs de nueva creacioacuten o modificados que han sido

validados para su instalacioacuten en el entorno de produccioacuten Las especificaciones

funcionales y teacutecnicas de una versioacuten estaacuten determinadas en la RFC

correspondiente

23 Clasificacioacuten de las Versiones

Las versiones pueden clasificarse seguacuten 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 caracteriacutesticas teacutecnicas etc

Versiones menores que suelen implicar la correccioacuten 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 raacutepida

un error conocido

Como pueden llegar a existir muacuteltiples versiones es conveniente definir una

referencia o coacutedigo que los identifique uniacutevocamente El sistema

universalmente aceptado es

Versiones mayores 10 20 etc

Versiones menores 11 12 13 etc

Versiones de emergencia 111 112 etc

Aunque en algunos casos esta clasificacioacuten se refina auacuten maacutes (vea por

ejemplo en la ayuda la versioacuten de su navegador)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 23

En su ciclo de vida una versioacuten puede encontrase en diversos estados

desarrollo pruebas produccioacuten y archivado11

En la Figura 8 nos ilustra graacuteficamente la evolucioacuten temporal de una versioacuten

Figura 8 Evolucioacuten temporal de una versioacuten

El despliegue de nuevas versiones puede realizarse de diferentes maneras y

es responsabilidad de la Gestioacuten de Cambios el determinar la forma maacutes

conveniente de hacerlo Entre las opciones maacutes habituales cabe contar

Versioacuten delta soacutelo se testean e instalan los elementos modificados

Esta opcioacuten tiene como ventaja su mayor simplicidad pero conlleva el

peligro de que puedan aparecer problemas e incompatibilidades en el

entorno de produccioacuten

Versioacuten completa Se distribuyen todos los elementos afectados ya

hayan sido modificados o no Aunque esta opcioacuten es obviamente maacutes

trabajosa es maacutes improbable que se generen incidentes tras la

instalacioacuten si se han realizado las pruebas pertinentes

11

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 24

Paquete de Versiones La Gestioacuten 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 opcioacuten es obligada por incompatibilidades entre una nueva

versioacuten con software o hardware previamente instalado Pensemos por

ejemplo en la migracioacuten a un nuevo sistema operativo que requiere

hardware maacutes avanzado yo nuevos versiones de los programas

ofimaacuteticos

24 Visioacuten General

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI12

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten de Versiones se resumen

sucintamente en la siguiente Figura 9

12

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 25

Figura 9 Visioacuten General de la Gestioacuten de Versiones

25 Planificacioacuten

Es crucial establecer un marco general para el lanzamiento de nuevas

versiones que fije una metodologiacutea 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

especiacuteficos que tomen en cuenta las peculiaridades de cada caso

A la hora de planificar correctamente el lanzamiento de una nueva versioacuten se

deben de tomar en cuenta los siguientes factores

Coacutemo puede afectar la nueva versioacuten a otras aacutereas del entramado TI

Queacute CIs se veraacuten directa o indirectamente implicados durante y tras el

lanzamiento de la nueva versioacuten

Coacutemo ha de construirse el entorno de pruebas para que eacuteste sea fiel

reflejo del entorno de produccioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 26

Queacute planes de back-out son necesarios

Coacutemo y cuaacutendo se deben implementar los planes de back-out para

minimizar el posible impacto negativo sobre el servicio y la integridad del

sistema TI

Cuaacuteles son los recursos humanos y teacutecnicos necesarios para llevar a

cabo la implementacioacuten de la nueva versioacuten con garantiacuteas de eacutexito

Quieacutenes seraacuten los responsables directos en las diferentes etapas del

proceso

Queacute planes de comunicacioacuten yo formacioacuten deben desarrollarse para

que los usuarios esteacuten puntualmente informados y puedan percibir la

nueva versioacuten como una mejora

Queacute tipo de despliegue es el maacutes adecuado completo delta

sincronizado en todas los emplazamientos gradual

Cuaacutel es la vida media uacutetil esperada de la nueva versioacuten

Queacute impacto puede tener el proceso de lanzamiento de la nueva versioacuten

en la calidad del servicio

Si es posible establecer meacutetricas precisas que determinen el grado de

eacutexito del lanzamiento de la nueva versioacuten

26 Desarrollo

La Gestioacuten de Versiones es la encargada del disentildeo y construccioacuten de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes

A veces el desarrollo se realizara en la casa y muchas otras requeriraacute la

participacioacuten de proveedores externos En este segundo caso la tarea de la

Gestioacuten de Versiones seraacute la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC Asimismo la Gestioacuten de Versiones seraacute la responsable de todo el

proceso de configuracioacuten necesario

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

Parte integrante del desarrollo lo componen los planes de back-out asociados

Estos tendraacuten que tomar en cuenta la disponibilidad acordada con los clientes

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

Es importante que las pruebas incluyan los planes de back-out para

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

Que meacutetricas determinan la puesta en marcha de los planes de back-out

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

informada por el Service Desk de los comentarios quejas incidentes etc que

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

recibidas y que se tomen las medidas correctivas necesarias para minimizar el

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

Es frecuente y a su vez un grave error que cuando se aborden cuestiones de

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

Es inuacutetil disponer de un sofisticado servicio TI si los usuarios debido a una

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

remotos mediante moacutedulos de e-learning sobre el funcionamiento de la

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 21: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 21

Proteccioacuten contra virus y problemas asociados a versiones de software

incontroladas

Las principales dificultades con las que topa la Gestioacuten de Versiones son

No existe una clara asignacioacuten de responsabilidades yo la organizacioacuten

TI no acepta la figura dominante de la Gestioacuten de Versiones en todo el

proceso de implementacioacuten 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 centralizacioacuten del

proceso de cambio Es habitual que existan reticencias a adoptar

sistemas estandarizados en toda la organizacioacuten sobre todo cuando

eacutesta no ha sido la poliacutetica tradicional de la misma

Se realizan cambios sin tener en cuenta a la Gestioacuten de Versiones

argumentado que estos soacutelo son responsabilidad de un determinado

grupo de trabajo o que su urgencia requeriacutea de ello

Hay resistencias a aceptar posibles planes de back-out Ciertos

entornos de produccioacuten pueden elegir ignorar lo problemas que una

nueva versioacuten puede provocar en otras aacutereas y resistirse a volver a la

uacuteltima versioacuten estable

La implementacioacuten sincronizada de versiones en entornos altamente

distribuidos

La solucioacuten a estos problemas pasa por

Un firme compromiso de la organizacioacuten con la Gestioacuten de Versiones y

sus responsables

Un adecuado plan de comunicacioacuten que informe a todos los

responsables y usuarios de la organizacioacuten TI de las ventajas de una

correcta gestioacuten de todo el proceso de cambio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 22

Una versioacuten es un grupo de CIs de nueva creacioacuten o modificados que han sido

validados para su instalacioacuten en el entorno de produccioacuten Las especificaciones

funcionales y teacutecnicas de una versioacuten estaacuten determinadas en la RFC

correspondiente

23 Clasificacioacuten de las Versiones

Las versiones pueden clasificarse seguacuten 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 caracteriacutesticas teacutecnicas etc

Versiones menores que suelen implicar la correccioacuten 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 raacutepida

un error conocido

Como pueden llegar a existir muacuteltiples versiones es conveniente definir una

referencia o coacutedigo que los identifique uniacutevocamente El sistema

universalmente aceptado es

Versiones mayores 10 20 etc

Versiones menores 11 12 13 etc

Versiones de emergencia 111 112 etc

Aunque en algunos casos esta clasificacioacuten se refina auacuten maacutes (vea por

ejemplo en la ayuda la versioacuten de su navegador)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 23

En su ciclo de vida una versioacuten puede encontrase en diversos estados

desarrollo pruebas produccioacuten y archivado11

En la Figura 8 nos ilustra graacuteficamente la evolucioacuten temporal de una versioacuten

Figura 8 Evolucioacuten temporal de una versioacuten

El despliegue de nuevas versiones puede realizarse de diferentes maneras y

es responsabilidad de la Gestioacuten de Cambios el determinar la forma maacutes

conveniente de hacerlo Entre las opciones maacutes habituales cabe contar

Versioacuten delta soacutelo se testean e instalan los elementos modificados

Esta opcioacuten tiene como ventaja su mayor simplicidad pero conlleva el

peligro de que puedan aparecer problemas e incompatibilidades en el

entorno de produccioacuten

Versioacuten completa Se distribuyen todos los elementos afectados ya

hayan sido modificados o no Aunque esta opcioacuten es obviamente maacutes

trabajosa es maacutes improbable que se generen incidentes tras la

instalacioacuten si se han realizado las pruebas pertinentes

11

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 24

Paquete de Versiones La Gestioacuten 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 opcioacuten es obligada por incompatibilidades entre una nueva

versioacuten con software o hardware previamente instalado Pensemos por

ejemplo en la migracioacuten a un nuevo sistema operativo que requiere

hardware maacutes avanzado yo nuevos versiones de los programas

ofimaacuteticos

24 Visioacuten General

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI12

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten de Versiones se resumen

sucintamente en la siguiente Figura 9

12

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 25

Figura 9 Visioacuten General de la Gestioacuten de Versiones

25 Planificacioacuten

Es crucial establecer un marco general para el lanzamiento de nuevas

versiones que fije una metodologiacutea 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

especiacuteficos que tomen en cuenta las peculiaridades de cada caso

A la hora de planificar correctamente el lanzamiento de una nueva versioacuten se

deben de tomar en cuenta los siguientes factores

Coacutemo puede afectar la nueva versioacuten a otras aacutereas del entramado TI

Queacute CIs se veraacuten directa o indirectamente implicados durante y tras el

lanzamiento de la nueva versioacuten

Coacutemo ha de construirse el entorno de pruebas para que eacuteste sea fiel

reflejo del entorno de produccioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 26

Queacute planes de back-out son necesarios

Coacutemo y cuaacutendo se deben implementar los planes de back-out para

minimizar el posible impacto negativo sobre el servicio y la integridad del

sistema TI

Cuaacuteles son los recursos humanos y teacutecnicos necesarios para llevar a

cabo la implementacioacuten de la nueva versioacuten con garantiacuteas de eacutexito

Quieacutenes seraacuten los responsables directos en las diferentes etapas del

proceso

Queacute planes de comunicacioacuten yo formacioacuten deben desarrollarse para

que los usuarios esteacuten puntualmente informados y puedan percibir la

nueva versioacuten como una mejora

Queacute tipo de despliegue es el maacutes adecuado completo delta

sincronizado en todas los emplazamientos gradual

Cuaacutel es la vida media uacutetil esperada de la nueva versioacuten

Queacute impacto puede tener el proceso de lanzamiento de la nueva versioacuten

en la calidad del servicio

Si es posible establecer meacutetricas precisas que determinen el grado de

eacutexito del lanzamiento de la nueva versioacuten

26 Desarrollo

La Gestioacuten de Versiones es la encargada del disentildeo y construccioacuten de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes

A veces el desarrollo se realizara en la casa y muchas otras requeriraacute la

participacioacuten de proveedores externos En este segundo caso la tarea de la

Gestioacuten de Versiones seraacute la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC Asimismo la Gestioacuten de Versiones seraacute la responsable de todo el

proceso de configuracioacuten necesario

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

Parte integrante del desarrollo lo componen los planes de back-out asociados

Estos tendraacuten que tomar en cuenta la disponibilidad acordada con los clientes

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

Es importante que las pruebas incluyan los planes de back-out para

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

Que meacutetricas determinan la puesta en marcha de los planes de back-out

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

informada por el Service Desk de los comentarios quejas incidentes etc que

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

recibidas y que se tomen las medidas correctivas necesarias para minimizar el

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

Es frecuente y a su vez un grave error que cuando se aborden cuestiones de

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

Es inuacutetil disponer de un sofisticado servicio TI si los usuarios debido a una

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

remotos mediante moacutedulos de e-learning sobre el funcionamiento de la

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 22: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 22

Una versioacuten es un grupo de CIs de nueva creacioacuten o modificados que han sido

validados para su instalacioacuten en el entorno de produccioacuten Las especificaciones

funcionales y teacutecnicas de una versioacuten estaacuten determinadas en la RFC

correspondiente

23 Clasificacioacuten de las Versiones

Las versiones pueden clasificarse seguacuten 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 caracteriacutesticas teacutecnicas etc

Versiones menores que suelen implicar la correccioacuten 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 raacutepida

un error conocido

Como pueden llegar a existir muacuteltiples versiones es conveniente definir una

referencia o coacutedigo que los identifique uniacutevocamente El sistema

universalmente aceptado es

Versiones mayores 10 20 etc

Versiones menores 11 12 13 etc

Versiones de emergencia 111 112 etc

Aunque en algunos casos esta clasificacioacuten se refina auacuten maacutes (vea por

ejemplo en la ayuda la versioacuten de su navegador)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 23

En su ciclo de vida una versioacuten puede encontrase en diversos estados

desarrollo pruebas produccioacuten y archivado11

En la Figura 8 nos ilustra graacuteficamente la evolucioacuten temporal de una versioacuten

Figura 8 Evolucioacuten temporal de una versioacuten

El despliegue de nuevas versiones puede realizarse de diferentes maneras y

es responsabilidad de la Gestioacuten de Cambios el determinar la forma maacutes

conveniente de hacerlo Entre las opciones maacutes habituales cabe contar

Versioacuten delta soacutelo se testean e instalan los elementos modificados

Esta opcioacuten tiene como ventaja su mayor simplicidad pero conlleva el

peligro de que puedan aparecer problemas e incompatibilidades en el

entorno de produccioacuten

Versioacuten completa Se distribuyen todos los elementos afectados ya

hayan sido modificados o no Aunque esta opcioacuten es obviamente maacutes

trabajosa es maacutes improbable que se generen incidentes tras la

instalacioacuten si se han realizado las pruebas pertinentes

11

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 24

Paquete de Versiones La Gestioacuten 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 opcioacuten es obligada por incompatibilidades entre una nueva

versioacuten con software o hardware previamente instalado Pensemos por

ejemplo en la migracioacuten a un nuevo sistema operativo que requiere

hardware maacutes avanzado yo nuevos versiones de los programas

ofimaacuteticos

24 Visioacuten General

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI12

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten de Versiones se resumen

sucintamente en la siguiente Figura 9

12

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 25

Figura 9 Visioacuten General de la Gestioacuten de Versiones

25 Planificacioacuten

Es crucial establecer un marco general para el lanzamiento de nuevas

versiones que fije una metodologiacutea 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

especiacuteficos que tomen en cuenta las peculiaridades de cada caso

A la hora de planificar correctamente el lanzamiento de una nueva versioacuten se

deben de tomar en cuenta los siguientes factores

Coacutemo puede afectar la nueva versioacuten a otras aacutereas del entramado TI

Queacute CIs se veraacuten directa o indirectamente implicados durante y tras el

lanzamiento de la nueva versioacuten

Coacutemo ha de construirse el entorno de pruebas para que eacuteste sea fiel

reflejo del entorno de produccioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 26

Queacute planes de back-out son necesarios

Coacutemo y cuaacutendo se deben implementar los planes de back-out para

minimizar el posible impacto negativo sobre el servicio y la integridad del

sistema TI

Cuaacuteles son los recursos humanos y teacutecnicos necesarios para llevar a

cabo la implementacioacuten de la nueva versioacuten con garantiacuteas de eacutexito

Quieacutenes seraacuten los responsables directos en las diferentes etapas del

proceso

Queacute planes de comunicacioacuten yo formacioacuten deben desarrollarse para

que los usuarios esteacuten puntualmente informados y puedan percibir la

nueva versioacuten como una mejora

Queacute tipo de despliegue es el maacutes adecuado completo delta

sincronizado en todas los emplazamientos gradual

Cuaacutel es la vida media uacutetil esperada de la nueva versioacuten

Queacute impacto puede tener el proceso de lanzamiento de la nueva versioacuten

en la calidad del servicio

Si es posible establecer meacutetricas precisas que determinen el grado de

eacutexito del lanzamiento de la nueva versioacuten

26 Desarrollo

La Gestioacuten de Versiones es la encargada del disentildeo y construccioacuten de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes

A veces el desarrollo se realizara en la casa y muchas otras requeriraacute la

participacioacuten de proveedores externos En este segundo caso la tarea de la

Gestioacuten de Versiones seraacute la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC Asimismo la Gestioacuten de Versiones seraacute la responsable de todo el

proceso de configuracioacuten necesario

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

Parte integrante del desarrollo lo componen los planes de back-out asociados

Estos tendraacuten que tomar en cuenta la disponibilidad acordada con los clientes

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

Es importante que las pruebas incluyan los planes de back-out para

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

Que meacutetricas determinan la puesta en marcha de los planes de back-out

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

informada por el Service Desk de los comentarios quejas incidentes etc que

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

recibidas y que se tomen las medidas correctivas necesarias para minimizar el

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

Es frecuente y a su vez un grave error que cuando se aborden cuestiones de

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

Es inuacutetil disponer de un sofisticado servicio TI si los usuarios debido a una

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

remotos mediante moacutedulos de e-learning sobre el funcionamiento de la

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 23: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 23

En su ciclo de vida una versioacuten puede encontrase en diversos estados

desarrollo pruebas produccioacuten y archivado11

En la Figura 8 nos ilustra graacuteficamente la evolucioacuten temporal de una versioacuten

Figura 8 Evolucioacuten temporal de una versioacuten

El despliegue de nuevas versiones puede realizarse de diferentes maneras y

es responsabilidad de la Gestioacuten de Cambios el determinar la forma maacutes

conveniente de hacerlo Entre las opciones maacutes habituales cabe contar

Versioacuten delta soacutelo se testean e instalan los elementos modificados

Esta opcioacuten tiene como ventaja su mayor simplicidad pero conlleva el

peligro de que puedan aparecer problemas e incompatibilidades en el

entorno de produccioacuten

Versioacuten completa Se distribuyen todos los elementos afectados ya

hayan sido modificados o no Aunque esta opcioacuten es obviamente maacutes

trabajosa es maacutes improbable que se generen incidentes tras la

instalacioacuten si se han realizado las pruebas pertinentes

11

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 24

Paquete de Versiones La Gestioacuten 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 opcioacuten es obligada por incompatibilidades entre una nueva

versioacuten con software o hardware previamente instalado Pensemos por

ejemplo en la migracioacuten a un nuevo sistema operativo que requiere

hardware maacutes avanzado yo nuevos versiones de los programas

ofimaacuteticos

24 Visioacuten General

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI12

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten de Versiones se resumen

sucintamente en la siguiente Figura 9

12

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 25

Figura 9 Visioacuten General de la Gestioacuten de Versiones

25 Planificacioacuten

Es crucial establecer un marco general para el lanzamiento de nuevas

versiones que fije una metodologiacutea 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

especiacuteficos que tomen en cuenta las peculiaridades de cada caso

A la hora de planificar correctamente el lanzamiento de una nueva versioacuten se

deben de tomar en cuenta los siguientes factores

Coacutemo puede afectar la nueva versioacuten a otras aacutereas del entramado TI

Queacute CIs se veraacuten directa o indirectamente implicados durante y tras el

lanzamiento de la nueva versioacuten

Coacutemo ha de construirse el entorno de pruebas para que eacuteste sea fiel

reflejo del entorno de produccioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 26

Queacute planes de back-out son necesarios

Coacutemo y cuaacutendo se deben implementar los planes de back-out para

minimizar el posible impacto negativo sobre el servicio y la integridad del

sistema TI

Cuaacuteles son los recursos humanos y teacutecnicos necesarios para llevar a

cabo la implementacioacuten de la nueva versioacuten con garantiacuteas de eacutexito

Quieacutenes seraacuten los responsables directos en las diferentes etapas del

proceso

Queacute planes de comunicacioacuten yo formacioacuten deben desarrollarse para

que los usuarios esteacuten puntualmente informados y puedan percibir la

nueva versioacuten como una mejora

Queacute tipo de despliegue es el maacutes adecuado completo delta

sincronizado en todas los emplazamientos gradual

Cuaacutel es la vida media uacutetil esperada de la nueva versioacuten

Queacute impacto puede tener el proceso de lanzamiento de la nueva versioacuten

en la calidad del servicio

Si es posible establecer meacutetricas precisas que determinen el grado de

eacutexito del lanzamiento de la nueva versioacuten

26 Desarrollo

La Gestioacuten de Versiones es la encargada del disentildeo y construccioacuten de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes

A veces el desarrollo se realizara en la casa y muchas otras requeriraacute la

participacioacuten de proveedores externos En este segundo caso la tarea de la

Gestioacuten de Versiones seraacute la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC Asimismo la Gestioacuten de Versiones seraacute la responsable de todo el

proceso de configuracioacuten necesario

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

Parte integrante del desarrollo lo componen los planes de back-out asociados

Estos tendraacuten que tomar en cuenta la disponibilidad acordada con los clientes

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

Es importante que las pruebas incluyan los planes de back-out para

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

Que meacutetricas determinan la puesta en marcha de los planes de back-out

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

informada por el Service Desk de los comentarios quejas incidentes etc que

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

recibidas y que se tomen las medidas correctivas necesarias para minimizar el

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

Es frecuente y a su vez un grave error que cuando se aborden cuestiones de

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

Es inuacutetil disponer de un sofisticado servicio TI si los usuarios debido a una

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

remotos mediante moacutedulos de e-learning sobre el funcionamiento de la

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 24: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 24

Paquete de Versiones La Gestioacuten 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 opcioacuten es obligada por incompatibilidades entre una nueva

versioacuten con software o hardware previamente instalado Pensemos por

ejemplo en la migracioacuten a un nuevo sistema operativo que requiere

hardware maacutes avanzado yo nuevos versiones de los programas

ofimaacuteticos

24 Visioacuten General

La Gestioacuten de Versiones es la encargada de la implementacioacuten y control de

calidad de todo el software y hardware instalado en el entorno de produccioacuten

La Gestioacuten de Versiones debe colaborar estrechamente con la Gestioacuten de

Cambios y de Configuraciones para asegurar que toda la informacioacuten relativa a

las nuevas versiones se integra adecuadamente en la CMDB de forma que

eacutesta se halle correctamente actualizada y ofrezca una imagen real de la

configuracioacuten de la infraestructura TI12

La Gestioacuten de Versiones tambieacuten debe mantener actualizada la Biblioteca de

Software Definitivo (DSL) donde se guardan copias de todo el software en

produccioacuten y el Depoacutesito de Hardware Definitivo (DHS) donde se almacenan

piezas de repuesto y documentacioacuten para la raacutepida reparacioacuten de problemas de

hardware en el entorno de produccioacuten

Las interacciones y funcionalidades de la Gestioacuten de Versiones se resumen

sucintamente en la siguiente Figura 9

12

httpitilosiatisesCurso_ITILGestion_Servicios_TIconceptos_basicos_gestion_de_versionesphp

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 25

Figura 9 Visioacuten General de la Gestioacuten de Versiones

25 Planificacioacuten

Es crucial establecer un marco general para el lanzamiento de nuevas

versiones que fije una metodologiacutea 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

especiacuteficos que tomen en cuenta las peculiaridades de cada caso

A la hora de planificar correctamente el lanzamiento de una nueva versioacuten se

deben de tomar en cuenta los siguientes factores

Coacutemo puede afectar la nueva versioacuten a otras aacutereas del entramado TI

Queacute CIs se veraacuten directa o indirectamente implicados durante y tras el

lanzamiento de la nueva versioacuten

Coacutemo ha de construirse el entorno de pruebas para que eacuteste sea fiel

reflejo del entorno de produccioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 26

Queacute planes de back-out son necesarios

Coacutemo y cuaacutendo se deben implementar los planes de back-out para

minimizar el posible impacto negativo sobre el servicio y la integridad del

sistema TI

Cuaacuteles son los recursos humanos y teacutecnicos necesarios para llevar a

cabo la implementacioacuten de la nueva versioacuten con garantiacuteas de eacutexito

Quieacutenes seraacuten los responsables directos en las diferentes etapas del

proceso

Queacute planes de comunicacioacuten yo formacioacuten deben desarrollarse para

que los usuarios esteacuten puntualmente informados y puedan percibir la

nueva versioacuten como una mejora

Queacute tipo de despliegue es el maacutes adecuado completo delta

sincronizado en todas los emplazamientos gradual

Cuaacutel es la vida media uacutetil esperada de la nueva versioacuten

Queacute impacto puede tener el proceso de lanzamiento de la nueva versioacuten

en la calidad del servicio

Si es posible establecer meacutetricas precisas que determinen el grado de

eacutexito del lanzamiento de la nueva versioacuten

26 Desarrollo

La Gestioacuten de Versiones es la encargada del disentildeo y construccioacuten de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes

A veces el desarrollo se realizara en la casa y muchas otras requeriraacute la

participacioacuten de proveedores externos En este segundo caso la tarea de la

Gestioacuten de Versiones seraacute la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC Asimismo la Gestioacuten de Versiones seraacute la responsable de todo el

proceso de configuracioacuten necesario

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

Parte integrante del desarrollo lo componen los planes de back-out asociados

Estos tendraacuten que tomar en cuenta la disponibilidad acordada con los clientes

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

Es importante que las pruebas incluyan los planes de back-out para

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

Que meacutetricas determinan la puesta en marcha de los planes de back-out

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

informada por el Service Desk de los comentarios quejas incidentes etc que

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

recibidas y que se tomen las medidas correctivas necesarias para minimizar el

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

Es frecuente y a su vez un grave error que cuando se aborden cuestiones de

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

Es inuacutetil disponer de un sofisticado servicio TI si los usuarios debido a una

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

remotos mediante moacutedulos de e-learning sobre el funcionamiento de la

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 25: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 25

Figura 9 Visioacuten General de la Gestioacuten de Versiones

25 Planificacioacuten

Es crucial establecer un marco general para el lanzamiento de nuevas

versiones que fije una metodologiacutea 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

especiacuteficos que tomen en cuenta las peculiaridades de cada caso

A la hora de planificar correctamente el lanzamiento de una nueva versioacuten se

deben de tomar en cuenta los siguientes factores

Coacutemo puede afectar la nueva versioacuten a otras aacutereas del entramado TI

Queacute CIs se veraacuten directa o indirectamente implicados durante y tras el

lanzamiento de la nueva versioacuten

Coacutemo ha de construirse el entorno de pruebas para que eacuteste sea fiel

reflejo del entorno de produccioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 26

Queacute planes de back-out son necesarios

Coacutemo y cuaacutendo se deben implementar los planes de back-out para

minimizar el posible impacto negativo sobre el servicio y la integridad del

sistema TI

Cuaacuteles son los recursos humanos y teacutecnicos necesarios para llevar a

cabo la implementacioacuten de la nueva versioacuten con garantiacuteas de eacutexito

Quieacutenes seraacuten los responsables directos en las diferentes etapas del

proceso

Queacute planes de comunicacioacuten yo formacioacuten deben desarrollarse para

que los usuarios esteacuten puntualmente informados y puedan percibir la

nueva versioacuten como una mejora

Queacute tipo de despliegue es el maacutes adecuado completo delta

sincronizado en todas los emplazamientos gradual

Cuaacutel es la vida media uacutetil esperada de la nueva versioacuten

Queacute impacto puede tener el proceso de lanzamiento de la nueva versioacuten

en la calidad del servicio

Si es posible establecer meacutetricas precisas que determinen el grado de

eacutexito del lanzamiento de la nueva versioacuten

26 Desarrollo

La Gestioacuten de Versiones es la encargada del disentildeo y construccioacuten de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes

A veces el desarrollo se realizara en la casa y muchas otras requeriraacute la

participacioacuten de proveedores externos En este segundo caso la tarea de la

Gestioacuten de Versiones seraacute la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC Asimismo la Gestioacuten de Versiones seraacute la responsable de todo el

proceso de configuracioacuten necesario

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

Parte integrante del desarrollo lo componen los planes de back-out asociados

Estos tendraacuten que tomar en cuenta la disponibilidad acordada con los clientes

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

Es importante que las pruebas incluyan los planes de back-out para

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

Que meacutetricas determinan la puesta en marcha de los planes de back-out

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

informada por el Service Desk de los comentarios quejas incidentes etc que

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

recibidas y que se tomen las medidas correctivas necesarias para minimizar el

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

Es frecuente y a su vez un grave error que cuando se aborden cuestiones de

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

Es inuacutetil disponer de un sofisticado servicio TI si los usuarios debido a una

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

remotos mediante moacutedulos de e-learning sobre el funcionamiento de la

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 26: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 26

Queacute planes de back-out son necesarios

Coacutemo y cuaacutendo se deben implementar los planes de back-out para

minimizar el posible impacto negativo sobre el servicio y la integridad del

sistema TI

Cuaacuteles son los recursos humanos y teacutecnicos necesarios para llevar a

cabo la implementacioacuten de la nueva versioacuten con garantiacuteas de eacutexito

Quieacutenes seraacuten los responsables directos en las diferentes etapas del

proceso

Queacute planes de comunicacioacuten yo formacioacuten deben desarrollarse para

que los usuarios esteacuten puntualmente informados y puedan percibir la

nueva versioacuten como una mejora

Queacute tipo de despliegue es el maacutes adecuado completo delta

sincronizado en todas los emplazamientos gradual

Cuaacutel es la vida media uacutetil esperada de la nueva versioacuten

Queacute impacto puede tener el proceso de lanzamiento de la nueva versioacuten

en la calidad del servicio

Si es posible establecer meacutetricas precisas que determinen el grado de

eacutexito del lanzamiento de la nueva versioacuten

26 Desarrollo

La Gestioacuten de Versiones es la encargada del disentildeo y construccioacuten de las

nuevas versiones siguiendo las pautas marcadas en las RFCs

correspondientes

A veces el desarrollo se realizara en la casa y muchas otras requeriraacute la

participacioacuten de proveedores externos En este segundo caso la tarea de la

Gestioacuten de Versiones seraacute la de asegurar que el paquete o paquetes de

software o hardware ofrecidos cumple las especificaciones detalladas en la

RFC Asimismo la Gestioacuten de Versiones seraacute la responsable de todo el

proceso de configuracioacuten necesario

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

Parte integrante del desarrollo lo componen los planes de back-out asociados

Estos tendraacuten que tomar en cuenta la disponibilidad acordada con los clientes

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

Es importante que las pruebas incluyan los planes de back-out para

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

Que meacutetricas determinan la puesta en marcha de los planes de back-out

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

informada por el Service Desk de los comentarios quejas incidentes etc que

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

recibidas y que se tomen las medidas correctivas necesarias para minimizar el

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

Es frecuente y a su vez un grave error que cuando se aborden cuestiones de

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

Es inuacutetil disponer de un sofisticado servicio TI si los usuarios debido a una

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

remotos mediante moacutedulos de e-learning sobre el funcionamiento de la

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 27: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 27

El desarrollo debe incluir si esto fuera necesario o simplemente recomendable

todos los scripts de instalacioacuten necesarios para el despliegue de la versioacuten

Estos scripts deberaacuten tener en cuenta aspectos tales como

Back-up automaacutetico de datos

Actualizaciones necesarias de las Bases de Datos asociadas

Instalacioacuten de las nuevas versiones en diferentes sistemas o

emplazamientos geograacuteficos

Creacioacuten de logs asociados al proceso de instalacioacuten

Parte integrante del desarrollo lo componen los planes de back-out asociados

Estos tendraacuten que tomar en cuenta la disponibilidad acordada con los clientes

en los SLAs correspondientes

27 Validacioacuten

Un bien planificado protocolo de tests es absolutamente indispensable para

lanzar al entorno de produccioacuten una nueva versioacuten con razonables garantiacuteas de

eacutexito

Las pruebas no deben limitarse a una validacioacuten de caraacutecter teacutecnico (ausencia

de errores) sino que tambieacuten deben realizarse pruebas funcionales con

usuarios reales para asegurarse de que la versioacuten cumple los requisitos

establecidos y es razonablemente usable (siempre existe una inevitable

resistencia al cambio en los usuarios que debe ser tenida en consideracioacuten)

Es importante que las pruebas incluyan los planes de back-out para

asegurarnos que se podraacute volver a la uacuteltima versioacuten estable de una forma

raacutepida ordenada y sin perdidas de valiosa informacioacuten

Las principales actividades realizadas en el proceso de prueba deben incluir

Pruebas del correcto funcionamiento de la versioacuten en un entorno

realista

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

Que meacutetricas determinan la puesta en marcha de los planes de back-out

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

informada por el Service Desk de los comentarios quejas incidentes etc que

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

recibidas y que se tomen las medidas correctivas necesarias para minimizar el

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

Es frecuente y a su vez un grave error que cuando se aborden cuestiones de

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

Es inuacutetil disponer de un sofisticado servicio TI si los usuarios debido a una

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

remotos mediante moacutedulos de e-learning sobre el funcionamiento de la

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 28: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 28

Pruebas de los procedimientos automaacuteticos o manuales de instalacioacuten

Listas de bugs o errores detectados si se diera el caso

Pruebas de los planes de back-out

Documentacioacuten para usuarios y personal de servicio

La Gestioacuten de Cambios seraacute la encargada de dar la validacioacuten final a la versioacuten

para que se proceda a su instalacioacuten Si la versioacuten no fuera aceptada se

devolveraacute a la Gestioacuten de Cambios para su reevaluacioacuten

28 Implementacioacuten

Llego el momento de la verdad la distribucioacuten de la nueva versioacuten tambieacuten

conocida como rollout

El rollout puede ser de varios tipos

Completo y sincronizado se realiza de manera integral y simultaacutenea

en todos los emplazamientos

Fragmentado ya sea bien espacial o temporalmente Por ejemplo

introduciendo la nueva versioacuten 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 especiacuteficas En

particular los usuarios finales deben estar puntualmente informados del

calendario de lanzamiento y de coacutemo 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

Cuaacutendo debe realizarse este proceso para diferentes grupos de trabajo

yo localizaciones geograacuteficas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

Que meacutetricas determinan la puesta en marcha de los planes de back-out

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

informada por el Service Desk de los comentarios quejas incidentes etc que

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

recibidas y que se tomen las medidas correctivas necesarias para minimizar el

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

Es frecuente y a su vez un grave error que cuando se aborden cuestiones de

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

Es inuacutetil disponer de un sofisticado servicio TI si los usuarios debido a una

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

remotos mediante moacutedulos de e-learning sobre el funcionamiento de la

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 29: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 29

Que meacutetricas determinan la puesta en marcha de los planes de back-out

y si estos deben ser completos o parciales

Tras la distribucioacuten la Gestioacuten de Versiones debe asegurarse de que

Se incluya una copia de la versioacuten en la DSL

El DHS incorpore repuestos funcionales de los nuevos CIs

La CMDB esteacute correctamente actualizada

Los usuarios estaacuten debidamente informados de las nuevas

funcionalidades y han recibido la formacioacuten necesaria para poder sacar

el adecuado provecho de las mismas

Tras la implementacioacuten la Gestioacuten de Versiones debe ser puntualmente

informada por el Service Desk de los comentarios quejas incidentes etc que

la nueva versioacuten haya podido suscitar Toda esta informacioacuten deberaacute ser

analizada para asegurar que las proacuteximas versiones incorporen las sugerencias

recibidas y que se tomen las medidas correctivas necesarias para minimizar el

impacto negativo que puedan tener futuros cambios

29 Comunicacioacuten y Formacioacuten

Es frecuente y a su vez un grave error que cuando se aborden cuestiones de

caraacutecter teacutecnico se obvie el factor humano

Salvo contadas excepciones es necesaria la interaccioacuten usuario-aplicacioacuten y

eacutesta suele representar el eslaboacuten maacutes deacutebil de la cadena

Es inuacutetil disponer de un sofisticado servicio TI si los usuarios debido a una

incompleta (in)formacioacuten no se encuentran en disposicioacuten de aprovechar sus

ventajas

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

remotos mediante moacutedulos de e-learning sobre el funcionamiento de la

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 30: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 30

La (in)formacioacuten debe estructurarse en distintos niveles

Los usuarios deben conocer el proacuteximo lanzamiento de una nueva

versioacuten y conocer con anterioridad la nueva funcionalidad planificada o

los errores que se pretenden resolver para participar a su discrecioacuten en

el proceso

Siempre que sea posible las pruebas de caraacutecter funcional deben ser

realizadas por un selecto grupo de usuarios finales Durante este

proceso de prueba se documentaraacuten y analizaraacuten

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 versioacuten

o La claridad de la documentacioacuten que se pondraacute a disposicioacuten del

usuario final

Cuando se considere oportuno se impartiraacuten cursos presenciales o

remotos mediante moacutedulos de e-learning sobre el funcionamiento de la

nueva versioacuten

Se desarrollaraacute una paacutegina de FAQs donde los usuarios puedan aclarar

las dudas maacutes habituales y puedan solicitar ayuda o soporte teacutecnico en

el uso de la nueva versioacuten

210 Control de Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la

Gestioacuten de Versiones

Para que estos informes ofrezcan una informacioacuten precisa y de sencilla

evaluacioacuten es necesario elaborar meacutetricas de referencia que cubran aspectos

tales como

Nuacutemero de lanzamientos de nuevas versiones

Nuacutemero de back-outs y razones de los mismos

Incidencias asociadas a nuevas versiones

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 31: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 31

Cumplimientos de los plazos previstos para cada despliegue

Asignacioacuten de recursos en cada caso

Correccioacuten 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 (formacioacuten inadecuada) de la

nueva versioacuten por parte de los usuarios

Disponibilidad del servicio durante y tras el proceso de lanzamiento de la

nueva versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 32: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 32

CAPITULO 3

CONTROL DE VERSIONES

31 Que es un Control de Versiones

Una versioacuten revisioacuten o edicioacuten de un producto es el estado en eacutel se encuentra

en un momento dado en su desarrollo o modificacioacuten Se llama control de

versiones a la gestioacuten de los diversos cambios que se realizan sobre los

elementos de alguacuten producto o una configuracioacuten del mismo Los sistemas de

control de versiones facilitan la administracioacuten de las distintas versiones de

cada producto desarrollado asiacute como las posibles especializaciones realizadas

(por ejemplo para alguacuten cliente especiacutefico)

El control de versiones se realiza principalmente en la industria informaacutetica para

controlar las distintas versiones del coacutedigo fuente Sin embargo los mismos

conceptos son aplicables a otros aacutembitos como documentos imaacutegenes sitios

web etceacutetera13

Aunque un sistema de control de versiones puede realizarse de forma manual

es muy aconsejable disponer de herramientas que faciliten esta gestioacuten (CVS

Subversion SourceSafe ClearCase Darcs Plastic SCM Git Mercurial etc)

311 Caracteriacutesticas

Un sistema de control de versiones debe proporcionar

Mecanismo de almacenaje de los elementos que deba gestionar (ej

archivos de texto imaacutegenes documentacioacuten)

Posibilidad de realizar cambios sobre los elementos almacenados (ej

modificaciones parciales antildeadir borrar renombrar o mover elementos)

13

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 33: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 33

Registro histoacuterico 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 uacutetil la generacioacuten de

informes con los cambios introducidos entre dos versiones informes de estado

marcado con nombre identificativo de la versioacuten de un conjunto de ficheros

etceacutetera

312 Clasificacioacuten

La principal clasificacioacuten que se puede establecer estaacute basada en el

almacenamiento del coacutedigo

Centralizados existe un repositorio centralizado de todo el coacutedigo del

cual es responsable un uacutenico 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 aprobacioacuten del responsable Algunos ejemplos son CVS y

Subversion

Distribuidos se aumenta la capacidad de decisioacuten distribuida Esto da

maacutes flexibilidad pero puede dificultar bastante la sincronizacioacuten

Ejemplos GIT y GNU Arch

313 Funcionamiento

Todos los sistemas de control de versiones se basan en disponer de un

repositorio que es el conjunto de informacioacuten 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 uacuteltima

versioacuten o cualquier versioacuten almacenada en el historial Este proceso se suele

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 34: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 34

conocer como check out o desproteger Para modificar la copia local existen

dos semaacutenticas baacutesicas

Exclusivos para poder realizar un cambio es necesario marcar en el

repositorio el elemento que se desea modificar y el sistema se encargaraacute

de impedir que otro usuario pueda modificar dicho elemento

Colaborativos en el que cada usuario se descarga la copia la modifica

y el sistema automaacuteticamente mezcla las diversas modificaciones El

principal problema es la posible aparicioacuten de conflictos que deban ser

solucionados manualmente o las posibles inconsistencias que surjan al

modificar el mismo fichero por varias personas no coordinadas Ademaacutes

esta semaacutentica no es apropiada para ficheros binarios

Tras realizar la modificacioacuten es necesario actualizar el repositorio con los

cambios realizados Habitualmente este proceso se denomina commit check in

o proteger

32 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 tambieacuten controladores de dispositivos y documentacioacuten

asociada

La DSL debe contener el histoacuterico completo de versiones de un mismo software

para proporcionar la versioacuten necesaria en caso de que se deban implementar

los planes de back-out14

La DSL debe ser almacenada en un entorno seguro y es conveniente que se

realicen back-up perioacutedicos

14

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 35: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 35

33 DHS (Depoacutesito de Hardware Definitivo)

El Depoacutesito de Hardware Definitivo (DHS) contiene piezas de repuesto para los

CIs (Configuration Items) en el entorno de produccioacuten

Los activos almacenados deben incorporarse a la CMDB (Database Change amp

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 Gestioacuten de Versiones se resumen en

Establecer una poliacutetica de planificacioacuten para la implementacioacuten 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 produccioacuten

Validar las nuevas versiones

Implementar las nuevas versiones en el entorno de produccioacuten

Llevar a cabo los planes de back-out o retirada de la nueva versioacuten 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 versioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 36: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 36

CAPITULO IV

ESTRUCTURA UN GESTOR DE VERSIONES

41 Introduccioacuten

Los gestores de versiones (version control system) tambieacuten llamados

herramientas de gestioacuten 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 uacutetiles

para todo tipo de documentos que sean revisados frecuentemente como

pueda ser el coacutedigo fuente de un programa su documentacioacuten 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 tambieacuten delegar en una

persona especializada en la administracioacuten de sistemas informaacuteticos

Aunque los gestores de versiones estaacuten pensados para grupos de trabajo

tambieacuten son muy uacutetiles para un programador individual ya que le ayuda a

llevar una cuenta histoacuterica de las diferentes versiones de sus ficheros

En el mundo de UNIX se han utilizado ampliamente cuatro programas para

gestioacuten de versiones

RCS (Revision Control System) El maacutes antiguo de todos y que ademaacutes

tiene su coacutedigo fuente publicado de forma gratuita por la Free Software

Foundation Praacutecticamente todos los sistemas UNIX lo tienen y Mac OS X

tambieacuten lo trae preinstalado

SCCS (Source Code Control System) Fue introducido por ATampT en el

Sistema V de UNIX y actualmente forma parte del estaacutendar XOpen Sin

embargo Mac OS X no lo trae preinstalado y nosotros no lo

estudiaremos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 37: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 37

CVS (Concurrent Version System) Estaacute basado en ReS y actualmente

es el gestor de versiones maacutes utilizado por los desarrolladores de software

libre en Internet

Subversioacuten Es el resultado de un reingenieriacutea sobre los conceptos de evs

para buscar una solucioacuten alternativa a los problemas maacutes comunes con lo

que se encuentran los usuarios de evs Actualmente su volumen de

usuarios estaacute creciendo raacutepidamente

En este documento estudiaremos evs y Subversioacuten 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

42 Porqueacute 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 quieacuten

es el responsable de cada cambio Para ello los gestores de versiones

mantienen un sistema de logs Ademaacutes los gestores de versiones siempre nos

permiten deshacer los cambios para ir a un estado anterior Tambieacuten 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 histoacuterico de revisiones desaparece el

problema de perder un coacutedigo cuando se modifica Ademaacutes mantener el

coacutedigo del proyecto centralizado ayuda a realizar copias de seguridad

Integracioacuten La integracioacuten se realiza impliacutecitamente seguacuten los

programadores guardan sus contribuciones en el repositorio

Contabilidad Es importante saber quieacuten y cuaacutendo se ha realizado cada

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 38: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 38

cambio en el proyecto El gestor de versiones permite guardar un histoacuterico

de quieacuten ha realizado cada cambio junto con comentarios que los propios

programadores guardan indicando el motivo del cambio

Branching Un mismo coacutedigo se puede utilizar en varios proyectos con soacutelo

hacer pequentildeas modificaciones Los gestores de versiones permiten crear una

liacutenea base llamada tronco (trunk) y varias ramas (branches) de un coacutedigo

fuente Ademaacutes 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 maacutes 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 coacutedigo fuente

Trabajo distribuido Los gestores de versiones modernos permiten

almacenar el coacutedigo fuente en un repositorio al que programadores de

distintas partes del mundo se conectan a traveacutes de Internet

43 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 atraacutes y recuperar una

versioacuten que teniacuteamos guardada 15

Para ello a las diferentes versiones se las da un nuacutemero de versioacuten al que

llamaremos revisioacuten que nos sirve para identificar luego cada versioacuten que

hayamos guardado Aunque muchas veces en la literatura a las revisiones

tambieacuten se las llama versiones nosotros usaremos el teacutermino revisiones para

evitar confusiones innecesarias

Conviene diferenciar entre versiones release de un programa y revisiones Las

15

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 39: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 39

versiones release son versiones que se sacan al puacuteblico cuando conseguimos

tener el programa en un estado estable mientras que las revisiones son las

que crea el programador cuando al final del diacutea decide guardar su trabajo en el

repositorio Es decir no tenga miedo de guardar tantas revisiones como quiera

Por uacuteltimo conviene comentar que el teacutermino variante se utiliza para referirnos

a varias versiones que coexisten en un mismo instante de tiempo (pe para

distintos sistemas operativos)

44 Modelos de configuracioacuten

Se llama modelo de configuracioacuten a la forma de organizar los ficheros que

componen un proyecto y a la forma de darles nombre El modelo de

configuracioacuten 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 Composicioacuten donde

un fichero estaacute formado por otros (pe las relaciones include) y dependencia

donde el contenido de un fichero depende de otro fichero

El espacio de reversiones muestra la evolucioacuten de un fichero a lo largo del

tiempo

Los gestores de versiones estaacuten pensados para que almacenen las diferentes

revisiones de un fichero de forma eficiente es decir soacutelo 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

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 40: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 40

1 Representacioacuten simeacutetrica donde dadas dos revisiones de un fichero T1

y T2 se almacenan las liacuteneas de texto que estaacuten en T1 y no estaacuten en T2 y

las que estaacuten en T2 y no estaacuten en T1 (veacutease Figura 11) es decir se

almacena que liacuteneas de texto estaacuten en cada versioacuten y no en la otra

2 Representacioacuten por cambios Donde se almacenan los cambios que

hay que hacer para pasar de T1 a T2

45 Versionado extensional e intencional

A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos

teacutecnicas de versionado

El maacutes conocido y normal es el versionado extensional (por antildeadidos) donde

se va numerando el contenido de cada fichero seguacuten 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 configuracioacuten del software haya varias

variantes y al acceder a la herramienta de gestioacuten de versiones indicamos queacute

versioacuten es la que queremos coger (pe Xll para Linux Cocoa para Mac OS X o

Win32 para Windows) Este versionado es muy tiacutepico gestionarlo con directivas

del propio lenguaje como por ejemplo de C

46 Gestores de versiones orientados a ficheros y a proyectos

En funcioacuten de la forma en que se asignan revisiones existen dos tipos de

gestores de versiones Los gestores de versiones orientados a ficheros (pe

CVS) donde los nuacutemeros de revisioacuten se asignan para cada fichero de forma

individual y los gestores de versiones orientados a proyectos (pe

Subversioacuten) donde el nuacutemero de revisioacuten se asigna a todos los ficheros que

componen el proyecto en un momento dado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 41: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 41

La Figura 12 muestra un ejemplo de nuacutemeros de revisioacuten asignados a los

ficheros de un proyecto en un momento dado en el caso de CVS Como

vemos cada fichero tiene un nuacutemero de revisioacuten distinto que corresponde con

el nuacutemero de veces que se ha modificado y guardado el fichero en el

repositorio 17

Las revisiones de nuacutemero maacutes alto de cada fichero corresponden al estado

actual del proyecto En los repositorios orientados a ficheros como cada

fichero crece de forma independiente es comuacuten realizar el tagging que

consiste en etiquetar las revisiones que tienen los ficheros en un momento

dado con el fin de poder recuperar maacutes tarde ese estado En CVS se puede

usar la etiqueta especial HEAD para referirse las uacuteltimas revisiones de todos

los ficheros del proyecto

Figura 10 Ejemplo de repositorio orientado a ficheros

17

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 42: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 42

CAPITULO V

ELEMENTOS DEL REPOSITORIO

51 Interaccioacuten con el repositorio

Normalmente se llama repositorio a un directorio situado en una maacutequina (que

actuacutea como servidor) donde se almacenan uno o maacutes 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 maacutequina que el

programador pero es maacutes comuacuten colocar en repositorio en una maacutequina

distinta y conectarse al repositorio a traveacutes de Internet siguiendo el modelo

cliente servidor

Los desarrolladores actuacutean como clientes y suelen bajarse una copia de uno o

maacutes proyectos a directorios de su maacutequina 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 homogeacutenea para las operaciones que puede realizar el

programador con su sandbox respecto al proyecto que son las siguientes

1 Import Es la operacioacuten de crear un proyecto en el respositorio a partir de

unos ficheros situados en un directorio de la maacutequina local Esta operacioacuten

suele realizarse soacutelo una vez al principio de un proyecto

2 Checkout Es la operacioacuten de bajarse un proyecto desde el repositorio a un

directorio de la maacutequina local Este directorio es el sandbox y ademaacutes 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 operacioacuten la realiza normalmente soacutelo una

vez cada programador que va a trabajar contra un proyecto almacenado en

un repositorio

3 Export Es una operacioacuten parecida a checkout pero en vez de estar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 43: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 43

destinada a programadores que desean crearse una sandbox estaacute

destinada a usuarios que quieren bajarse el coacutedigo fuente sin ficheros

adicionales de metadatos Es decir con la operacioacuten export el usuario no

obtiene un sandbox sino soacutelo un directorio con los ficheros del proyecto

listos para ser compilados

4 Commit Una vez que el desarrollador modifica uno o maacutes ficheros del

proyecto eacuteste debe subir los cambios al proyecto del repositorio usando la

operacioacuten de commit Cuando se hace un commit tanto CVS como

Subversion piden introducir un mensaje con una descripcioacuten de los cambios

realizados

S Update Cuando un programador actualiza el proyecto los demaacutes

desarrolladores pueden bajarse estos cambios utilizando la operacioacuten 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 operacioacuten de

update En este caso el gestor de versiones es lo suficientemente inteligente

como para actualizar en el sandbox soacutelo las liacuteneas de coacutedigo 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 coacutedigo No

tenga ninguacuten miedo a realizar las operaciones commit y update con tanta

frecuencia como sea necesario (incluso cuanto maacutes frecuentemente lo haga

mejor) y no se preocupe si otros programadores esteacuten tambieacuten modificando el

proyecto del repositorio Los gestores de versiones son lo suficientemente

inteligentes como para no destrozar su coacutedigo En la seccioacuten 2 veremos que a

veces se pueden producir conflictos pero que su resolucioacuten es maacutes sencilla de

lo que pueda parecer

En cualquier caso y como regla general se recomienda seguir el siguiente

paradigma de interaccioacuten con el proyecto del repositorio

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 44: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 44

La operacioacuten de update la puede realizar tantas veces como quiera Por

ejemplo la puede realizar todos los diacuteas por la mantildeana antes de ponerse a

trabajar en su proyecto o despueacutes de venir de comer Si su coacutedigo

compilaba antes del update deberaacute seguir compilando despueacutes del update

Si no es asiacute puede usar las herramientas de logs que proporciona el gestor

de versiones para identificar quieacuten ha subido el cambio y vaya a hablar con

eacutel inmediatamente Si en su grupo de trabajo es frecuente que el coacutedigo

deje de compilar correctamente despueacutes de hacer un update es un siacutentoma

de que una o maacutes personas en su grupo de trabajo no son muy

competentes

La operacioacuten de commit se debe realizar soacutelo inmediatamente despueacutes de

hacer un update y soacutelo cuando se dispone de un coacutedigo que compila y ejecuta

correctamente La primera condicioacuten 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 condicioacuten

garantiza que los demaacutes programadores no se encuentren con un proyecto con

coacutedigo que ni siquiera compila Un siacutentoma claro de que el gestor de versiones

no se estaacute usando correctamente Tenga en cuenta que tampoco es

conveniente que los periodos de commit se alarguen demasiados Cuando maacutes

se alarguen los periodos de commit maacutes trabajo se perderaacute si su maacutequina falla

Cuando se hace commit el gestor de versiones pide un comentario textual que

explique los cambios que se han realizado Es muy comuacuten 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 deberiacutea incluir este mensaje estaacuten Por queacute se ha

hecho el cambio queacute funcionalidad se ha antildeadido cambiado y eliminado Por

uacuteltimo conviene comentar que un error comuacuten por parte de los recieacuten llegados

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 45: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 45

a un gestor de versiones es intentar almacenar en el proyecto del repositorio

todos los ficheros de su proyecto En general en un repositorio soacutelo deben de

almacenarse los ficheros de coacutedigo fuente (pe e h Makefile) que sirven

para generar el programa asiacute como los ficheros de documentacioacuten (pe doe

ppt) pero no deberiacuteamos de almacenar los ficheros que se producen durante la

generacioacuten del programa como los 0 los lib los dll o los exe Estos ficheros

hacen crecer mucho el tamantildeo del repositorio y no tiene sentido almacenarlos

ya que siempre se pueden generar a partir de los ficheros de coacutedigo 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 maacutequina donde se situacutee el sandbox Los ficheros

Makefile o Ant son una excepcioacuten a esta regla siempre que se disentildeen de

forma que no dependan de rutas absolutas En el caso de que nuestro proyecto

utilice ficheros de ejemplo como imaacutegenes jpg o viacutedeos mpg estos tambieacuten

se pueden almacenar en un directorio destinada a iconos o casos de prueba

52 Resolucioacuten de conflictos

Tanto CVS como Subversioacuten siguen el paradigma de que varios

programadores pueden modificar concurrentemente los ficheros del proyecto y

despueacutes 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 liacutenea a liacutenea

Si 105 cambios estaacuten en diferentes liacuteneas el sistema antildeade reemplaza o

elimina liacuteneas seguacuten proceda La operacioacuten de mezcla seraacute satisfactoria

siempre que dos programadores no hayan modificado la misma liacutenea En caso

de que ambos hayan modificado la misma liacutenea se produciraacute un conflicto (a no

ser que hayan modificado exactamente las mismas liacuteneas con el mismo

contenido)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 46: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 46

En teoriacutea la operacioacuten de mezcla podriacutea realizarse tanto en la operacioacuten de

commit como en la operacioacuten 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 revisioacuten del sandbox es maacutes antigua que

la del proyecto del repositorio) la operacioacuten de mezcla siempre se realiza

durante el update Teacutengase en cuenta que la operacioacuten 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 depositaacutendose 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 sentildeala la o las liacuteneas conflictivas En

este momento debemos indicar cuaacutel de las dos liacuteneas es la correcta (para lo

cual si tenemos dudas podemos consultar al otro programador) Una vez

indicado cuaacutel es la liacutenea o liacuteneas 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 operacioacuten de commit

53 Tagging

Aunque poder obtener la uacuteltima revisioacuten de 105 ficheros de un proyecto en el

repositorio es uacutetil tambieacuten es muy uacutetil poder obtener los ficheros del proyecto

en la revisioacuten en la que se encontraban en alguacuten hito pasado (pe en la versioacuten

10 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

quisieacuteramos obtener estaacute configuracioacuten

En el caso de CVS como muestra la Figura 12 a los ficheros se les asigna

nuacutemeros de revisioacuten de forma individual con lo que el tagging se realiza

poniendo la misma etiqueta a cada fichero en su nuacutemero de revisioacuten actual Por

su parte Subversioacuten implementa el tagging mediante copias ligeras (cheap

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 47: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 47

copies) que consiste en hacer una copia del proyecto (que normalmente estaacute

en un directorio llamado trunk) en otro directorio (que normalmente estaraacute

metido dentro del directorio tags)

Subversion no asigna nuacutemeros de revisioacuten de forma individual a cada fichero

sino que por cada revisioacuten que guardamos en el proyecto del repositorio asigna

un nuacutemero de revisioacuten para todos los ficheros del proyecto Cuando en

Subversion hacemos una copia ligera no estamos copiando el contenido del

fichero (en la revisioacuten actual y en todas las anteriores) sino que soacutelo estamos

apuntando al contenido de la revisioacuten actual en otra ruta Esto permite que el

tagging no consuma muchos recursos Debido a que las copias ligeras son un

puntero a una revisioacuten soacutelo pueden hacerse copias ligeras de todos los

ficheros del proyecto

Las estrategias de tagging son muy diversas pero momentos tiacutepicos en los que

se hace tagging del proyecto son Cuando se cumple un hito cuando se

termina una versioacuten release del proyecto antes de empezar a eliminar una

funcionalidad o antes de empezar a modificar la forma en que estaacute

implementada una parte del proyecto

54 Branching

A la liacutenea principal de desarrollo normalmente se la llama tronco (trunk) El

branching consiste en crear una o maacutes liacuteneas de desarrollo distintas a las que

se llama ramas (branches)

Existen varias razones para crear una rama Una razoacuten muy usada es para

mantenimiento y correccioacuten de errores de una versioacuten release del producto

mientras que el tronco se utiliza para antildeadir nueva funcionalidad Otra razoacuten es

crear una rama para hacer cambios experimentales o reingenieriacutea de coacutedigo

que en el futuro se podraacuten antildeadir o no al tronco de la aplicacioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 48: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 48

El gestor de versiones construye la rama y el tronco a partir de las mismas

revisiones de Coacutedigo 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 deberiacuteamos saber que conviene crear una rama antes de empezar

a modificar el coacutedigo pero en ocasiones no se decide que conviene crear una

rama hasta que el coacutedigo ha empezado a ser modificado en este caso

podemos hacer un branching retroactivo pero hacer un branching retroactivo

siempre es maacutes complicado que si desde el principio se decide empezar a

trabajar en otra rama

En Subversioacuten la rama debe de incluir todos los ficheros del proyecto Por

contra CVS permite que la rama soacutelo incluya uno o maacutes 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 comuacuten que

acabe necesitaacutendose incluir nuevos ficheros en la rama lo cual complica su

mantenimiento 18

541 Nuacutemeros de revisioacuten

Tanto CVS como Subversioacuten asignan un nuacutemero diferente a cada revisioacuten 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

Subversioacuten es orientado a proyecto es decir asigna un mismo nuacutemero de

revisioacuten 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

12 a cada fichero se le va asignando nuacutemeros de revisioacuten distintos

18

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 49: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 49

El segundo aspecto a destacar es que Subversioacuten utiliza nuacutemeros consecutivos

para cada revisioacuten que se guarda en el proyecto del repositorio

independientemente de si la revisioacuten corresponde al tronco o a una rama En la

Figura 11(a) vemos que los nuacutemeros de revisioacuten en el tronco y en la rama no

tienen porque ser consecutivos

Sin embargo como muestra la Figura 11 (b) CVS asigna nuacutemeros de revisioacuten

compuestos por varios nuacutemeros separados por punto En el caso del tronco el

nuacutemero de revisioacuten suele1 empezar por 1 y despueacutes le sigue el nuacutemero de

revisioacuten del tronco En el caso de las ramas las ramas estaacuten formadas por tres

diacutegitos Los dos primeros diacutegitos indican la base de la rama y el tercero es un

nuacutemero par que indica el nuacutemero de rama para esa revisioacuten Por uacuteltimo el

cuarto diacutegito se destina a indicar el nuacutemero de revisioacuten para una rama

En cualquier caso la forma en que un gestor de versiones asigna nuacutemeros a las

revisiones debe ser vista de forma transparente por parte del usuario es decir

no se preocupe por queacute nuacutemero de revisioacuten le corresponde a cada revisioacuten que

guarde Si le interesa recordar una revisioacuten por alguacuten motivo utilice tagging 19

Figura 11(a)Branching

Figura 11(b) Branching en supervisioacuten

19

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 50: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 50

542 Mezclar ramas

Podemos hacer una operacioacuten de mezcla consistente en aplicar una rama al

tronco en cuyo caso aplicamos los cambios que h3ya sufrido la rama durante

las revisiones de eacutesta a la revisioacuten maacutes reciente del tronco Cuaacutendo esta

mezcla es deseable depende de la finalidad para la que se creoacute la rama Si es

una rama de mantenimiento y correccioacuten de errores seguramente sea

deseable hacer esta mezcla Tambieacuten podriacutea ser interesante aplicar esta

mezcla si la rama se creoacute para desarrollar un coacutedigo experimental o para hacer

reingenieriacutea de coacutedigo y el trabajo realizado en la rama fue satisfactorio

1 Es posible crear varios troncos para un mismo fichero en cuyo caso el

nuacutemero empezariacutea por 2 3 etc pero es algo que no se recomienda y no

vamos a estudiar aquiacute Es decir el primer diacutegito indica el nuacutemero 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

Tambieacuten es posible aplicar un tronco a una rama en cuyo caso aplicamos los

cambios que ha sufrido el tronco a la revisioacuten maacutes reciente de la rama

543 Estrategias de branching

En general el tronco representa la principal liacutenea de desarrollo del proyecto

todas las variantes deberiacutean almacenarse en ramas El principal problema

surge a la hora de decidir si el tronco deberiacutea mantener coacutedigo estable o si el

mantenimiento y reparacioacuten de errores deberiacutea realizarse en las ramas Esto da

lugar a las dos principales estrategias de branching que vamos a comentar a

continuacioacuten Troncos estables y troncos inestables

544 Troncos estables

La estrategia de troncos estables dice que el tronco deberiacutea mantener coacutedigo

que esteacute siempre listo para release Las ramas se usan para desarrollo

introducir nueva funcionalidad experimental para refactorizacioacuten de coacutedigo etc

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 51: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 51

La variante maacutes 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 coacutedigo fuente abierto la estrategia de troncos estables es la maacutes

popular ya que cualquier usuario puede bajarse en cualquier momento el

coacutedigo de nuestro proyecto del repositorio compilarlo y todo le deberiacutea de

funcionar

Otra variante menos estricta dice que el coacutedigo se enviacutea al tronco una vez

acabado (lo que se suele llamar versioacuten beta o release candidate) y en este

momento se crea una rama de aseguramiento de calidad que es la rama de la

que saldraacute la versioacuten release del producto A partir del momento en que

saquemos la versioacuten release del producto se crea una rama de mantenimiento

en la que se corrigen posibles errores que surjan maacutes adelante en la versioacuten

publicada

Las ventajas de esta estrategia son que siempre tenemos coacutedigo estable en el

tronco y que si los desarrollos que hacemos en una rama acaban retrasaacutendose

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 coacutedigo de

la rama puede diferir bastante del coacutedigo 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

545 Troncos inestables

En esta estrategia el tronco se utiliza para ir guardando las uacuteltimas versiones

de coacutedigo y cuando se quiere sacar una versioacuten release del producto se crea

una rama en la que se realiza el aseguramiento de calidad y mantenimiento de

errores

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 52: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 52

Esta estrategia es la maacutes usada por consultoras y pequentildeas empresas que

realizan programas de coacutedigo cerrado ya que no existe el problema de que

otras personas esteacuten accediendo a nuestro proyecto del repositorio y tengan

que encontrar coacutedigo estable

La principal ventaja de esta estrategia es que es maacutes sencilla de seguir ya que

a menudo todo el desarrollo (incluido el aseguramiento de calidad y

mantenimiento de errores) se realiza en el tronco con lo que desaparece el

problema de tener que mezclar ramas

El principal inconveniente de esta estrategia es que el tronco suele contener

coacutedigo erroacuteneo que en ocasiones ni si quiera compila Si decide utilizar la

estrategia de troncos inestables el tagging perioacutedico de revisiones estables

puede reducir este inconveniente

546 Tipos de ramas

En cualquier momento podemos aplicar los cambios realizados en una rama al

tronco Una vez aplicados los cambios de la rama al tronco podemos seguir

trabajando en la rama o bien abandonar el desarrollo sobre esa rama Por

desgracia los gestores de versiones no suelen proporcionar en mecanismo

para cerrar una rama sino que lo maacutes que podemos hacer es dejar de

trabajar sobre esa rama

La forma en que usamos las ramas ha dado lugar a dos tipos de ramas que

vamos a describir a continuacioacuten Las ramas largas que son ramas que se

mezclan varias veces con el tronco y las ramas cortas que son ramas que

una vez mezcladas con el tronco no se vuelven a usar

547 Ramas largas

Una forma de trabajar con ramas largas es la que muestra la Figura 12 (a)

donde los cambios hechos es la rama se aplican al tronco perioacutedicamente Esto

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 53: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 53

se hace cuando las ramas estaacuten destinadas a aseguramiento de calidad y

mantenimiento de coacutedigo En este caso los errores encontrados y corregidos

se deben llevar perioacutedicamente al tronco del proyecto Sin embargo la nueva

funcionalidad antildeadida al tronco no se suele transportar a las ramas de

mantenimiento

(c) Rama larga Aplicar en ambos sentidos

Figura 12 Ramas largas

Una segunda forma de trabajar con ramas largas es la que muestra la Figura

12 (b) donde los cambios realizados en el tronco se aplican a las ramas Esto

es uacutetil en situaciones en las que los cambios hechos en las ramas no deben de

afectar al tronco pero los cambios del tronco siacute que son uacutetiles para la rama

Por ejemplo si el tronco representa una libreriacutea especializada para

procesamiento de imaacutegenes que realizar nuestra empresa y la rama

representa una aplicacioacuten que estamos personalizando para un determinado

cliente las mejoras en la libreriacutea pueden pasarse a la rama utilizando este

modelo

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 54: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 54

La tercera forma de trabajar que muestra la Figura 12 (c) es un modelo mixto

en el que los cambios se aplican en ambos sentidos Esto permite que tronco y

ramas se sincronicen perioacutedicamente Este modelo es uacutetil cuando seguimos la

estrategia de troncos estables y hay varios desarrolladores trabajando en

distintas ramas Cuando el desarrollo hecho en una rama alcanza un estado

estable su contenido se puede aplicar al tronco y tambieacuten se pueden aplicar

los cambios del tronco a las ramas para mantener las ramas actualizadas

548 Ramas cortas

Las ramas cortas son ramas que sirven para realizar una tarea concreta y cuyo

contenido no se vuelve a usar una vez aplicada la rama al tronco Cuando se

usan ramas cortas es muy comuacuten utilizar ramas cortas en cascada tal como

muestra la Figura 13

Figura 13 Ramas cortas en cascada

Las ramas cortas en cascada simulan una rama larga en la que los cambios se

aplican en ambos sentidos Para evitar tener que aplicar los cambios de la

rama al tronco y luego los cambios del tronco a la rama lo que se hace para

mantener las ramas actualizadas es aplicar la rama al tronco y crear otra rama

Durante la planificacioacuten de un proyecto se debe de elegir una estrategia de

branching y el tipo de ramas que se van a utilizar en el proyecto Si un proyecto

no tiene una poliacutetica de branching definida se suele acabar con un montoacuten de

ramas cuya finalidad es difiacutecil de identificar

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 55: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 55

55 Ficheros de texto y ficheros binarios

Tanto CVS como Subversioacuten utilizan las liacuteneas de los ficheros de texto para

identificar los cambios entre dos revisiones antildeadir borrar o modificar liacuteneas

CVS almacena los ficheros de texto con las liacuteneas acabadas siempre al estilo

UNIX (en LF) Cuando antildeadimos al proyecto del repositorio un fichero de texto

con liacuteneas al estilo Windows (acabadas en CRLF) o Mac OS Classic

(acabadas en CR) CVS modifica el final de liacutenea para almacenar el fichero de

texto en el proyecto del repositorio al estilo UNIX y vuelve a poner el final de

liacutenea correspondiente a la plataforma cuando el fichero se lleva del proyecto del

repositorio al sandbox Por su parte Subversioacuten nunca modifica los finales de

liacutenea de los ficheros

El hecho de que el gestor de versiones modifique el final de liacutenea dependiendo

de la plataforma donde esteacute el sandbox tiene la ventaja de que las liacuteneas de los

ficheros de texto siempre tienen el final de liacutenea preferido pero el

inconveniente de que si el fichero es binario su contenido se deteriora si se

interpretan coacutedigos binarios como coacutedigos de final de liacutenea Para evitar este

problema en CVS debemos de marcar a los ficheros binarios como fichero

binarios de esta forma CVS no modificaraacute los finales de liacutenea del fichero1

Otra diferencia importante entre los ficheros de texto y los ficheros binarios es

que los repositorios trabajan en modo merge soacutelo cuando se trata de ficheros

de texto es decir almacenan los cambios entre revisiones soacutelo en el caso de

los ficheros de texto En el caso de los ficheros binarios los repositorios

trabajan en modo copy en el que siempre que modificamos un fichero binario

se crea otra copia en el repositorio Loacutegicamente el modo copy implica mayor

gasto de espacio de almacenamiento aunque los gestores de versiones usan

un algoritmo de compresioacuten basado en diferencias binarias para reducir este

consumo

En el caso de CVS el modo copy se utiliza cuando el fichero estaacute marcado

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 56: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 56

como binario si no por defecto se utiliza el modo merge En el caso de

Subversioacuten no existe un mecanismo para marcar expliacutecitamente a los ficheros

como binarios sino que Subversioacuten identifica automaacuteticamente su tipo MIME

Si su tipo es text las revisiones del fichero se almacenan en modo merge en

caso contrario las revisiones del fichero se almacenan en modo copy

56 Herramientas de productividad

Este documento explica el manejo de CVS y Subversioacuten desde un terminal ya

que esta es la forma de poder acceder a toda la funcionalidad que un gestor de

versiones ofrece Sin embargo una vez que se ha aprendido a usar CVS o

Subversioacuten muchos programadores prefieren usar herramientas graacuteficas que

les simplifican el acceso al repositorio o aumentan su productividad Creemos

que es mejor que empiece leyendo este tutorial y una vez sepa manejar estas

herramientas desde el terminal empiece a usar la herramienta de productividad

que maacutes le guste

CVS puede ser directamente accedido desde herramientas de desarrollo como

Xcode o NetBeans tambieacuten existen herramientas para Mac OS X como

MacCVS para Linux como Cervisia para Windows como o WinCVS o

multiplataforma como SmartCVS Subversioacuten proporciona herramientas como

RapidSVN o SmartSVN que funciona en Mac OS X Linux y Windows

57 Hook scripts

Los gestores de versiones suelen permitir que el administrador instale scripts

en el repositorio que se ejecutan cuando un usuario va a interactuar con el

repositorio Por ejemplo cuando se recibe un commit se puede comprobar que

el mensaje de lag sigua un determinado patroacuten o que el coacutedigo fuente haya

sido escrito de acuerdo a las poliacuteticas de la empresa Tanto CVS como

subversioacuten permite instalar hook scripts

1 Conviene observar que un error muy tiacutepico cometido por los recieacuten llegados a

CVS es no marcar los ficheros binarios como tal con lo que luego se

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 57: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 57

encuentran con CVS estropea alguno de sus ficheros binarios

58 Repositorios distribuidos

Algunos sistemas de gestioacuten de versiones como Arch el nuevo gestor de

versiones de GNU o Subversioacuten versioacuten 14 o posterior soportan repositorios

distribuidos los cuales son especialmente uacutetiles para proyectos grandes Un

repositorio distribuido no es maacutes que un repositorio del que existen varios

mirror cuyo contenido se sincroniza perioacutedicamente

En este documento no estudiaremos coacutemo configurar Subversioacuten para crear

repositorios distribuidos pero el usuario interesado puede buscar esta

informacioacuten al acabar de leer este documento

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 58: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 58

CAPIacuteTULO 6

CONCLUSIONES Y RECOMENDACIONES

61 Conclusiones

El software cambia con el tiempo por diversas razones es necesario controlar

esta evolucioacuten suele ser necesario recuperar versiones antiguas para ello se

ha investigado detenidamente a la Gestioacuten de Versiones

ITIL es una metodologiacutea que ayuda a que las cosas se puedan hacer de una

forma maacutes eficiente ya que lo que se propone es que se adopten ciertas

meacutetricas y procedimientos que otros proveedores de IT adoptaron y que

gracias a ellas son catalogadas como mejores praacutecticas

El hecho de adoptar mejores praacutecticas implica que no tengamos que descubrir

el hilo negro y que si alguien sabe coacutemo hacer las cosas y explotar los recursos

nos podemos apoyar en eacutel para que nosotros tambieacuten podamos hacerlo El

mayor objetivo es que todos lleguemos a un nivel de eficiencia que se traduzca

en una buena prestacioacuten de servicios

Es por ello que hay que considerar que ITIL conlleva un cambio cultural en la

organizacioacuten lo que seraacute clave para el eacutexito de su correcta gestioacuten

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 59: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 59

62 Recomendaciones

Saber en queacute consiste exactamente ITIL y coacutemo abordarlo es una de las

principales claves para el eacutexito de cualquier proyecto que se acometa en

este campo Asiacute uno de los errores que muchos responsables de

departamentos de TI han cometido a la hora de desarrollar un proyecto

de implantacioacuten de herramientas de gestioacuten de los servicios de TI ha

sido pensar que el objetivo era implantar ITIL cuando realmente es el

medio para ayudar a la principal finalidad mejorar el servicio prestado

El cliente debe enfocar ITIL como una metodologiacutea que ofrece

recomendaciones sobre queacute hacer y queacute no pero el coacutemo hacerlas

depende de paraacutemetros muy variados como el tipo de negocio o aacuterea de

actividad de cada empresa o institucioacuten de su cultura corporativa del

tamantildeo de su departamento de TI de su madurez en la gestioacuten y de sus

objetivos entre otros aspectos

Debe tener en cuenta las nuevas versiones de software y estar siempre

actualizado

Concretar por queacute y para queacute seriacutea conveniente la instalacioacuten de estas

praacutecticas de ITIL tambieacuten hay otro aspecto destacable que no hay que

dejar pasar por alto

Identificar aquellos proyectos que se ha visto que es necesario realizar a

partir del anaacutelisis de la situacioacuten actual Junto a ello la necesidad de

automatizar estos procesos utilizando soluciones que aceleren la

adopcioacuten de estas mejores praacutecticas se erigen como puntos

fundamentales

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 60: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 60

GLOSARIO

Repositorio

El repositorio es el lugar en el que se almacenan los datos actualizados

e histoacutericos a menudo en un servidor A veces se le denomina depoacutesito

o depot Puede ser un sistema de archivos en un disco duro un banco

de datos etc

Moacutedulo

Conjunto de directorios yo archivos dentro del repositorio que

pertenecen a un proyecto comuacuten

Rotular (tag)

Darle a alguna versioacuten de cada uno de los ficheros del moacutedulo en

desarrollo en un momento preciso un nombre comuacuten (etiqueta oacute

roacutetulo) para asegurarse de reencontrar ese estado de desarrollo

posteriormente bajo ese nombre En la praacutectica se rotula a todos los

archivos en un momento determinado Para eso el moacutedulo se congela

durante el rotulado para imponer una versioacuten coherente Pero bajo

ciertas circunstancias puede ser necesario utilizar versiones de algunos

ficheros que no coinciden temporalmente con las de los otros ficheros

del moacutedulo

Revisioacuten (versioacuten)

Una revisioacuten es una versioacuten determinada de un archivo

Liacutenea base (Baseline)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 61: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 61

Una revisioacuten aprobada de un documento o fichero fuente a partir del

cual se pueden realizar cambios subsiguientes

Injertar rama (branch)

Un moacutedulo puede ser branched o bifurcado en un momento de tiempo

de forma que desde ese momento en adelante dos copias de esos

ficheros puedan ser desarrolladas a diferentes velocidades o de

diferentes formas de modo independiente El moacutedulo tiene entonces 2

(oacute maacutes) ramas

Desplegar (Check-out) (checkout co)

Un despliegue crea una copia de trabajo local desde el repositorio Se

puede especificar una revisioacuten especiacutefica y por defecto se suele obtener

la uacuteltima

Enviar oacute Commit (check-in ci install submit)

Un commit sucede cuando una copia de los cambios hechos a una

copia local es escrita o integrada sobre repositorio

Conflicto

Un conflicto ocurre en las siguientes circunstancias

los usuarios X e Y despliegan versiones del archivo A en que las liacuteneas

n1 hasta n2 son comunes

el usuario X enviacutea cambios entre las liacuteneas n1 y n2 al archivo A

el usuario Y no actualiza el archivo A tras el enviacuteo del usuario X

el usuario Y realiza cambios entre las liacuteneas n1 y n2

el usuario Y intenta posteriormente enviar esos cambios al archivo A

El sistema es incapaz de fusionar los cambios El usuario Y debe resolver el

conflicto combinando los cambios o eligiendo uno de ellos para descartar el

otro

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 62: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 62

Resolver

El acto de la intervencioacuten del usuario para atender un conflicto entre

diferentes cambios al mismo documento

Cambio (change diff delta)

Un cambio representa una modificacioacuten especiacutefica a un documento bajo

control de versiones La granularidad de la modificacioacuten considerada un

cambio variacutea entre diferentes sistemas de control de versiones

Lista de cambios (changelist change set patch)

En muchos sistemas de control de versiones con commits multi-cambio

atoacutemicos una lista de cambios identifica el conjunto de cambios hechos

en un uacutenico commit Esto tambieacuten puede representar una vista

secuencial del coacutedigo fuente permitiendo que el fuente sea examinado a

partir de cualquier identificador de lista de cambios particular

Exportacioacuten (export)

Una exportacioacuten es similar a un check-out salvo porque crea un aacuterbol

de directorios limpio sin los metadatos de control de versiones presentes

en la copia de trabajo Se utiliza a menudo de forma previa a la

publicacioacuten de los contenidos

Importacioacuten (import)

Una importacioacuten es la accioacuten de copia un aacuterbol de directorios local (que

no es en ese momento una copia de trabajo) en el repositorio por

primera vez

Integracioacuten oacute fusioacuten (merge)

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 63: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 63

Una integracioacuten oacute fusioacuten une dos conjuntos de cambios sobre un

fichero o un conjunto de ficheros en una revisioacuten unificada de dicho

fichero o ficheros

Esto puede suceder cuando un usuario trabajando en esos

ficheros actualiza su copia local con los cambios realizados y

antildeadidos al repositorio por otros usuarios Anaacutelogamente este

mismo proceso puede ocurrir en el repositorio cuando un usuario

intenta check-in sus cambios

Puede suceder despueacutes de que el coacutedigo haya sido branched y

un problema anterior al branching sea arreglado en una rama y

se necesite incorporar dicho arreglo en la otra

Puede suceder despueacutes de que los ficheros hayan sido

branched desarrollados de forma independiente por un tiempo y

que entonces se haya requerido que fueran fundidos de nuevo en

un uacutenico trunk unificado

Integracioacuten inversa

El proceso de fundir ramas de diferentes equipos en el trunk principal del

sistema de versiones

Actualizacioacuten (sync oacute update)

Una actualizacioacuten integra los cambios que han sido hechos en el

repositorio (por ejemplo por otras personas) en la copia de trabajo

local

Copia de trabajo

La copia de trabajo es la copia local de los ficheros de un repositorio

en un momento del tiempo o revisioacuten especiacuteficos Todo el trabajo

realizado sobre los ficheros en un repositorio se realiza inicialmente

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 64: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 64

sobre una copia de trabajo de ahiacute su nombre Conceptualmente es un

cajoacuten de arena o sandbox

Congelar

Congelar significa permitir los uacuteltimos cambios (commits) para

solucionar las fallas a resolver en una entrega (release) y suspender

cualquier otro cambio antes de una entrega con el fin de obtener una

versioacuten consistente Si no se congela el repositorio un desarrollador

podriacutea comenzar a resolver una falla cuya resolucioacuten no estaacute prevista y

cuya solucioacuten deacute lugar a efectos colaterales imprevistos

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 65: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 65

BIBLIOGRAFIacuteA

httpwwwmonografiascomtrabajos31metodologia-itilmetodologia-

itilshtml

httpitilosiatisesCurso_ITILGestion_Servicios_TIgestion_v

wwwmonografiascomtrabajos38cobitcobitshtmlparaq

httpmacprogramadoresorgtutorialestutorialescvssvnpdf

httpwwwwikipediaorgwikiITIL

Manuales de introduccioacuten a la implementacioacuten de ITIL

PDFrsquos de Internet

PDFrsquos de Internet

Libro Gestioacuten de Servicios TI de Jan Van

Libro ISACA de Miguel

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 66: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 66

INDICE

FIRMA DE RESPONSABILIDADhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipii

CERTIFICACIOacuteNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellipiii

AGRADECIMIENTOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphellipiv

DEDICATORIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip hellip v

INTRODUCCIOgraveNhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip helliphelliphellipvi

CAPITULO I 1

INTRODUCCIOacuteN A ITIL 1

11 Definicioacuten de ITIL 1

12 El objetivo de usar ITIL en Managed Services 2

13 Concepto de soluciones para ITIL desde el punto de vista de

negocio 5

14 Certificacioacuten 6

15 Historia y precursores de ITIL 7

16 Criacuteticas a ITIL 8

17 Forma de uso de ITIL en Managed Services 9

CAPITULO II 19

GESTION DE VERSIONES 19

21 Introduccioacuten y Objetivos 19

22 Beneficios y Dificultades 20

23 Clasificacioacuten de las Versiones 22

24 Visioacuten General 24

25 Planificacioacuten 25

26 Desarrollo 26

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 67: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 67

27 Validacioacuten 27

28 Implementacioacuten 28

29 Comunicacioacuten y Formacioacuten 29

210 Control de Proceso 30

CAPITULO 3 32

CONTROL DE VERSIONES 32

31 Que es un Control de Versiones 32

311 Caracteriacutesticas 32

312 Clasificacioacuten 33

313 Funcionamiento 33

32 DSL (Definitive Software Library) 34

33 DHS (Depoacutesito de Hardware Definitivo) 35

CAPITULO IV 36

ESTRUCTURA UN GESTOR DE VERSIONES 36

41 Introduccioacuten 36

42 Porqueacute usar un repositorio 37

43 Revisiones versiones release y variantes 38

44 Modelos de configuracioacuten 39

45 Versionado extensional e intencional 40

46 Gestores de versiones orientados a ficheros y a proyectos 40

CAPITULO V 42

ELEMENTOS DEL REPOSITORIO 42

51 Interaccioacuten con el repositorio 42

52 Resolucioacuten de conflictos 45

53 Tagging 46

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65

Page 68: INTRODUCCIÓN A ITIL - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/Bilioteca de... · 1.5 Historia y precursores de ITIL Lo que actualmente se conoce como

ITIL GESTION DE VERSIONES

Investigador Mariacutea Eugenia Bravo Campoverde Pagina 68

54 Branching 47

541 Nuacutemeros de revisioacuten 48

542 Mezclar ramas 50

543 Estrategias de branching 50

544 Troncos estables 50

545 Troncos inestables 51

546 Tipos de ramas 52

547 Ramas largas 52

548 Ramas cortas 54

55 Ficheros de texto y ficheros binarios 55

56 Herramientas de productividad 56

57 Hook scripts 56

58 Repositorios distribuidos 57

CAPIacuteTULO 6 58

CONCLUSIONES Y RECOMENDACIONES 58

61 Conclusiones 58

62 Recomendaciones 59

GLOSARIO 60

BIBLIOGRAFIacuteA 65