introducciÓn a itil - dspace.ucacue.edu.ecdspace.ucacue.edu.ec/bitstream/reducacue/4154/4/bilioteca...
TRANSCRIPT
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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