Upload
ivan-cl
View
214
Download
0
Embed Size (px)
Citation preview
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 1
CAPITULO I
INTRODUCCIN A ITIL
1.1 Definicin de ITIL
ITIL son las siglas de una metodologa desarrollada a finales de los aos 80s
por iniciativa del gobierno del Reino Unido, especficamente por la OGC u
Oficina Gubernativa de Comercio Britnica (Office of Goverment Comerce). Las
siglas de ITIL significan (Information Technology Infrastructure Library) o
Librera de Infraestructura de Tecnologas de Informacin.
Esta metodologa es la aproximacin ms globalmente aceptada para la
gestin de servicios de Tecnologas de Informacin en todo el mundo, ya que
es una recopilacin de las mejores prcticas tanto del sector pblico como del
sector privado. Estas mejores prcticas de dan en base a toda la experiencia
adquirida con el tiempo en determinada actividad, y son soportadas bajo
esquemas organizacionales complejos, pero a su vez bien definidos, y que se
apoyan en herramientas de evaluacin e implementacin.
ITIL brinda una descripcin detallada de un nmero de prcticas importantes en
IT, a travs de una amplia lista de verificacin, tareas, procedimientos y
responsabilidades que pueden adaptarse a cualquier organizacin IT. En
algunos casos hasta se han definido las prcticas como procesos que cubren
las actividades ms importantes de las organizaciones de servicio IT. La vasta
cantidad de temas cubiertos por las publicaciones transforma a la ITIL en un
elemento de referencia til para fijar nuevos objetivos de mejora para la
organizacin IT. La organizacin puede crecer y madurar con ellos.
En base a ITIL se han desarrollado varios sistemas para la Administracin de
Servicio IT, generalmente organizaciones del negocio. Los ejemplos incluyen
Hewlett & Packard (HP ITSM modelo de referencia), IBM (IT Modelo de
Proceso), Microsoft (MOF) y muchos otros. sta es una de las razones por las
que ITIL se ha convertido en el estndar de facto para describir varios procesos
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 2
fundamentales de la Administracin de Servicio IT. Esta adopcin y adaptacin
de ITIL refleja la filosofa de ITIL, y es un desarrollo bienvenido ya que la ITIL
se ha transformado en el tan necesario orden imprescindible para el actual
medio heterogneo y dividido de IT.
ITIL fue desarrollada al reconocer que las organizaciones dependen cada vez
ms de IT para alcanzar sus objetivos corporativos. Esta dependencia en
aumento ha dado como resultado una necesidad creciente de servicios IT de
calidad que se correspondan con los objetivos del negocio, y que satisfaga los
requisitos y las expectativas del cliente.
ITIL ofrece un marco comn para todas las actividades del departamento IT,
como parte de la provisin de servicios, basado en la infraestructura IT. Estas
actividades se dividen en procesos, que dan un marco eficaz para lograr una
Administracin de Servicio IT ms madura. Cada uno de estos procesos cubre
una o ms tareas del departamento IT, tal como desarrollo de servicio,
administracin de infraestructura, y provisin y soporte de los servicios. Este
planteo del proceso permite describir las mejores prcticas de la Administracin
de Servicio IT independientemente de la estructura de organizacin real de la
entidad.
1.2 El objetivo de usar ITIL en Managed Services
ITIL como metodologa propone el establecimiento de estndares que nos
ayuden en el control, operacin y administracin de los recursos (ya sean
propios o de los clientes). Plantea hacer una revisin y reestructuracin de los
procesos existentes en caso de que estos lo necesiten (si el nivel de eficiencia
es bajo o que haya una forma ms eficiente de hacer las cosas), lo que nos
lleva a una mejora continua.
Otra de las cosas que propone es que para cada actividad que se realice se
debe de hacer la documentacin pertinente, ya que esta puede ser de gran
utilidad para otros miembros del rea, adems de que quedan asentados todos
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 3
los movimientos realizados, permitiendo que toda la gente est al tanto de los
cambios y no se tome a nadie por sorpresa.
En la documentacin se pone la fecha en la que se hace el cambio, una breve
descripcin de los cambios que se hicieron, quien fue la persona que hizo el
cambio, as como quien es el que autorizo el cambio, para que as se lleve todo
un seguimiento de lo que pasa en el entorno. Esto es ms que nada como
mtodo con el que se puede establecer cierto control en el sistema de cambios,
y as siempre va a haber un responsable y se van a decir los procedimientos y
cambios efectuados.
Las ventajas de ITIL para los clientes y usuarios
Mejora la comunicacin con los clientes y usuarios finales a travs de los
diversos puntos de contacto acordados.
Los servicios se detallan en lenguaje del cliente y con ms detalles.
Se maneja mejor la calidad y los costos de los servicios.
La entrega de servicios se enfoca mas al cliente, mejorando con ello la
calidad de los mismos y relacin entre el cliente y el departamento de IT.
Una mayor flexibilidad y adaptabilidad de los servicios.
Ventajas de ITIL para TI
La organizacin TI desarrolla una estructura ms clara, se vuelve ms eficaz,
y se centra ms en los objetivos de la organizacin.
La administracin tiene un mayor control, se estandarizan e identifican los
procedimientos, y los cambios resultan ms fciles de manejar.
La estructura de procesos en IT proporciona un marco para concretar de
manera ms adecuada los servicios de outsourcing.
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 4
A travs de las mejores prcticas de ITIL se apoya al cambio en la cultura de
TI y su orientacin hacia el servicio, y se facilita la introduccin de un sistema
de administracin de calidad.
ITIL proporciona un marco de referencia uniforme para la comunicacin
interna y con proveedores.
Desventajas
Tiempo y esfuerzo necesario para su implementacin.
Que no se d el cambio en la cultura de las reas involucradas.
Que no se vea reflejada una mejora, por falta de entendimiento sobre
procesos, indicadores y como pueden ser controlados.
Que el personal no se involucre y se comprometa.
La mejora del servicio y la reduccin de costos puede no ser visible.
Que la inversin en herramientas de soporte sea escasa. Los procesos
podrn parecer intiles y no se alcancen las mejoras en los servicios.
La Figura 1 indica el manejo de servicios que lleva el negocio a travs de la
Tecnologa ITIL.
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 5
Figura 1: ITIL en Managed Services
1.3 Concepto de soluciones para ITIL desde el punto de vista de negocio
Segn la Figura 2 vemos como aparentemente tenemos segmentos del
negocio aislados, pero en realidad todos tienen algo que ver para la obtencin
de las soluciones. Por ejemplo la prestacin de servicios muchas veces no
sera posible sin la gestin de infraestructura, asimismo las perspectivas del
negocio no se daran sin la prestacin de servicio y los servicios no serian
posibles sin un soporte al servicio. Y el punto de interaccin que se da entre
estos segmentos del negocio es la bsqueda de soluciones, donde lo que se
busca es que las perspectivas del negocio estn soportadas en base a la
prestacin de servicios; la prestacin de servicios requiere que se le de un
soporte al servicio para que este siempre disponible, la disponibilidad la
podemos lograr mediante una gestin de la infraestructura y en lugar de tener
al centro las soluciones vamos a tener a los clientes satisfechos.
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 6
Las reas de un negocio no pueden estar aisladas unas de otras. El punto de
interaccin que se da entre las diferentes reas de un negocio es la bsqueda
de soluciones, donde lo que se pretende es que las perspectivas del negocio
estn soportadas entre s por medio del sistema.1
Figura2: Soluciones para ITIL desde el punto de vista de negocio
1.4 Certificacin
Los particulares pueden conseguir varias certificaciones oficiales ITIL. Los
estndares de calificacin ITIL son gestionados por la ITIL Certification
Management Board (ICMB) que agrupa a la OGC, a itSMF International y a los
dos Institutos Examinadores existentes: EXIN (con sede en los Pases Bajos) e
ISEB (con sede en el Reino Unido).
Existen tres niveles de certificacin ITIL para profesionales:
1. Foundation Certificate (Certificado Bsico): acredita un conocimiento
bsico de ITIL en gestin de servicios de tecnologas de la informacin y
1 http://www.monografias.com/trabajos31/metodologia-itil/metodologia-itil.shtml
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 7
la comprensin de la terminologa propia de ITIL. Est destinado a
aquellas personas que deseen conocer las buenas prcticas
especificadas en ITIL.
2. Practitioner's Certificate (Certificado de Responsable): destinado a
quienes tienen responsabilidad en el diseo de procesos de
administracin de departamentos de tecnologas de la informacin y en
la planificacin de las actividades asociadas a los procesos.
3. Manager's Certificate (Certificado de Director): garantiza que quien lo
posee dispone de profundos conocimientos en todas las materias
relacionadas con la administracin de departamentos de tecnologas de
la informacin, y lo habilita para dirigir la implantacin de soluciones
basadas en ITIL.
No es posible certificar una organizacin o sistema de gestin como conforme
a ITIL, pero una organizacin que haya implementado las guas de ITIL sobre
Gestin de los Servicios de TI puede lograr certificarse bajo la ISO/IEC 20000.2
La versin 3 de ITIL, que apareci en junio de 2007, cambi ligeramente el
esquema de Certificaciones, existiendo certificaciones puentes, se definen 3
niveles:
1. Basic Level (Equivalente a ITIL Foundation en v2)
2. Management and Capability Level (Equivalente a los niveles Practitioner
y Manager en ITIL v2)
3. Advanced Level (nuevo en v3)
1.5 Historia y precursores de ITIL
Lo que actualmente se conoce como ITIL versin 1, desarrollada bajo el
auspicio de la CCTA, se titul Government Information Technology
Infrastructure Method (Mtodo de Infraestructura de la Tecnologa de 2 http://es.wikipedia.org/wiki/Information_Technology_Infrastructure_Library
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 8
Informacin del Gobierno, GITM) y durante varios aos termin expandindose
hasta unos 31 libros dentro de un proyecto inicialmente dirigido por Peter
Skinner y John Stewart. Las publicaciones fueron retituladas principalmente
como resultado del deseo (por Roy Dibble de la CCTA) de que fueran vistas
como una gua y no como un mtodo formal, y como resultado del creciente
inters que haba fuera del gobierno britnico.
Muchos de los conceptos principales de gestin de servicios no surgieron
dentro del proyecto inicial de la CCTA para desarrollar ITIL. IBM afirma que sus
Yellow Books (A Management System for the Information Business, Un
sistema de gestin para el negocio de la informacin)[4] [5] fueron precursores
claves. Segn IBM:
A principios de los aos 1980, IBM document los conceptos originales de
Gestin de Sistemas en una serie de cuatro volmenes titulada A Management
System for Information Systems (sic). Estos ampliamente aceptados yellow
books [...] fueron aportaciones claves para el conjunto originales de libros de
ITIL.
Otras publicaciones de IBM y comentarios de los autores de ITIL aclaran que
los yellow books fueron cruciales para el desarrollo del Servicio de Soporte
pero que el volumen de Entrega de Servicios no tom prestado de ellos hasta
tales extremos.
1.6 Crticas a ITIL
ITIL ha recibido crticas de varios frentes. Entre ellas:
El hecho de que muchos defensores de ITIL parecen creer que es un
marco holstico y completo para el gobierno de TI.
Su tendencia a convertirla en una religin.
Como seala Jan van Bon (autor y editor de muchas publicaciones de Gestin
de Servicios de TI).
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 9
Hay mucha confusin sobre ITIL, procedente de todo tipo de malentendidos
sobre su naturaleza. ITIL, como afirma la OGC, es un conjunto de buenas
prcticas. La OGC no afirma que dichas mejoras prcticas describan procesos
puros, ni tampoco que ITIL sea un marco diseado como un modelo coherente.
Eso es lo que la mayora de sus usuarios hacen de ella, probablemente porque
tienen una gran necesidad de dicho modelo. 3
El columnista CIO Magazine Dean Meyer tambin ha expuesto algunos puntos
de vista cautelosos sobre ITIL, incluyendo cinco trampas tpicas tales como
convertirse en esclavo de definiciones desactualizadas y dejar que ITIL se
convierta en religin. Como Meyer seala, ITIL no describe el abanico
completo de procesos necesarios para ser lderes. Se centra en [...] gestionar
servicios actuales.4
La calidad de los volmenes de la biblioteca se considera desigual. Por
ejemplo, Van Herwaarden y Grift sealan que la consistencia que
caracterizaba los procesos de soporte al servicio [...] se pierde en gran medida
en los libros de entrega de servicio.5
1.7 Forma de uso de ITIL en Managed Services
ITIL postula que el servicio de soporte, la administracin y la operacin se
realiza a travs de cinco procesos:
1. Manejo de Incidentes
2. Manejo de problemas
3. Manejo de configuraciones
4. Manejo de cambios y
5. Manejo de entregas
3 Jan van Bon (autor y editor de muchas publicaciones de Gestin de Servicios de TI).
4 CIO Magazine Dean Meyer
5 Van Herwaarden y Grift
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 10
1.7.1 PROCESO DE MANEJO DE INCIDENTES
Su objetivo primordial es restablecer el servicio lo ms rpido posible para
evitar que el cliente se vea afectado, esto se hace con la finalidad de que se
minimicen los efectos de la operacin. Se dice que el proveedor de debe de
encargar de que el cliente no debe percibir todas aquellas pequeas o grandes
fallas que llegue a presentar el sistema. A este concepto se le llama
disponibilidad (que el usuario pueda tener acceso al servicio y que nunca se
vea interrumpido).
Para este proceso se tiene un diagrama que en cada una de sus fases maneja
cuatro pasos bsicos que son: propiedad, monitoreo, manejo de secuencias y
comunicacin.
En el proceso de manejo de incidentes vemos en la Figura 3 que se da como
primera etapa la deteccin del incidente (es cuando el sistema presenta alguna
anomala o falla, y que esto se puede traducir en un error en el sistema o que el
usuario no puede hacer algo y recurre a pedir ayuda); ya que lo tenemos
identificado se hace una clasificacin del incidente (vemos si el error que se
presenta es conocido o si nunca se ha presentado) y de la mano va el soporte
inicial (es el punto en el que el cliente llega a la mesa de servicio a solicitar
ayuda, porque no sabe o no puede hacer algo); en caso de que el incidente sea
conocido se hace el procedimiento de solicitud de servicio (se ejecutan los
pasos a seguir segn el manual de procedimientos para poder llegar a la
solucin de una forma viable y eficiente); una vez que ya que se la dio una
solucin al incidente por medio del manual de procedimientos se recurre a la
documentacin y contabilizacin del incidente, para ver qu tanta incidencia
tiene este caso; finalmente se hace una evaluacin para ver si efectivamente
se resolvi el incidente de forma satisfactoria y en supuesto de ser afirmativa
se cierra el incidente y el otro supuesto seria que de la solucin que se planteo
no es lo suficientemente eficiente o acertada para que resuelva el problema y
se recurre a hacer una investigacin y un diagnostico de la situacin para ver
cmo es que se puede atacar el problema de frente y resolverlo; una vez que
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 11
se tiene todo un contexto analizado se recurre a la ejecucin de la propuesta
de solucin del incidente y se hace un estudio para ver si el incidente es
recuperable o si es caso perdido (la mayora de los casos son recuperables,
peo cuando el nivel de dao es muy fuerte, se da el caso de que se d por
perdido); y finamente se cierra el incidente y esta solucin se documenta en
una base de datos a la que se le llama base del conocimiento o Knowledge
Data Base (aqu vienen documentadas todas las soluciones, y se establecen
los pasos a seguir para que se hagan de forma eficiente) para que al momento
de volverse a presentar el incidente ya va a estar documentado y esto hace
que sea ms fcil, rpida y eficiente su resolucin.6
Figura 3: Proceso de manejo de incidentes
1.7.2 PROCESO DE MANEJO DE PROBLEMAS
El Objetivo de este proceso es prevenir y reducir al mximo los incidentes, y
esto nos lleva a una reduccin en el nivel de incidencia. Por otro lado nos
6 http://www.monografias.com/trabajos31/metodologia-itil/metodologia-itil.shtml
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 12
ayuda a proporcionar soluciones rpidas y efectivas para asegurar el uso
estructurado de recursos.
En este proceso lo que se busca es que se pueda tener pleno control del
problema, esto se logra dndole un seguimiento y un monitoreo al problema.
La figura 4 de este proceso es muy particular, ya que se maneja en dos fases:
la primera est relacionada con lo que es el control del problema y la segunda
es con el control del error.7
En lo que respecta a la fase de control del problema: primero se tiene que
identificar el problema en base a alguna sintomatologa; ya que tenemos este
antecedente, pasamos a la clasificacin de los problemas (en este proceso al
igual que en el proceso de manejo de incidentes tenemos que ver si es un
problema conocido), en caso de ser conocido, se recurre al procedimiento de
solicitud de servicio, donde se van a aplicar las soluciones de acuerdo a como
estn en el manual de procedimientos; y en caso de no ser conocido se tendra
que hacer una fase de investigacin para ver qu es lo que genera el problema
y ms tarde hacer un diagnostico; ya que tenemos un diagnstico tenemos que
hacer un RFC (Request For Change o Solicitud de Cambio),
Esta solicitud de cambio implica que se va a tener que implementar la solucin
y finalmente se va a hacer una evaluacin para ver si se resolvi el problema
de raz. En caso de que si se funcione esta solucin se pasa a la
documentacin.
Con lo que respecta a la segunda fase del modelo, el control del error se hace
por medio de una identificacin del error en general, posteriormente se hace
una especie de registro, y este va a servir para clasificar el error; ya que se
tiene una clasificacin y se recurre a una evaluacin de que tanto dao genero
o puede llegar a generar el error, esto con la finalidad de cuantificar los
desperfectos que podra llegar a causar en caso de que el error prevalezca y
no se solucione; posteriormente se hace la resolucin o correccin del error
7 http://www.monografias.com/trabajos31/metodologia-itil/metodologia-itil.shtml#proceso
ITIL: GESTION DE VERSIONES
Investigador: Mara 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 difcil, que es
determinar que problemas estn asociados o como es que al momento de
cambiar algo el sistema, se va a cambiar de forma uniforme y no se va a
alterar, y que presente inconsistencias. Por ejemplo que es lo que pasara si
cambio algunos de los datos en la configuracin del sistema, se tendra que
afectar el sistema de manera uniforme para que siga en equilibrio y no est
cambiado en algunas partes y en otras que se quede como estaba antes.
Figura 4: Proceso de manejo de problemas
1.7.3 PROCESO DE MANEJO DE CONFIGURACIONES
Su objetivo es proveer con informacin real y actualizada de lo que se tiene
configurado e instalado en cada sistema del cliente.
Este proceso es de los ms complejos como muestra la Figura 5, ya que se
mueve bajo cuatro vrtices que son: administracin de cambios, administracin
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 14
de liberaciones, administracin de configuraciones y la administracin de
procesos diversos.8
El nivel de complejidad de este modelo es alto, ya que influyen muchas
variables y muchas de ellas son dinmicas, entonces al cambiar una o varias
de ellas se afecta el sistema en general, lo que hace que sea muy difcil de
manipular. Aunque es lo ms parecido a la realidad, porque nuestro entorno es
dinmico y las decisiones de unos afectan a otros. Por ejemplo en lo que
respecta a la administracin de cambios vemos que se relaciona directamente
con la administracin de incidentes y de problemas, lo que conlleva una
planeacin, identificacin, control, seguimiento del status, verificacin y
auditoria de configuraciones, lo que hace que haya muchas variables.
En otro ejemplo la implementacin de cambios implica que se tiene que hacer
la liberacin y distribucin de nuevas versiones, esto de da por una fase de
planeacin, identificacin, control, revisin del status, verificacin y auditoria, y
puede depender de la administracin de las capacidades, ya que si no se
cuenta con el software o con el hardware esta fase no se podra llevar a cabo; y
as se hara con todos los niveles hasta llegar al cierre del control de cambios.
8 http://www.monografias.com/trabajos31/metodologia-itil/metodologia-itil.shtml#proceso
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 15
Figura 5: Proceso de manejo de configuraciones
1.7.4 PROCESO DE CONTROL DE CAMBIOS
El objetivo de este proceso es reducir los riesgos tanto tcnicos, econmicos y
de tiempo al momento de la realizacin de los cambios.
La Figura 6 al parecer es muy fcil de seguir, pero en realidad no lo es, ya que
entre etapa y etapa se da una fase de monitoreo para ver que no se han sufrido
desviaciones de los objetivos.9
Primero vemos que tenemos un registro y clasificacin del cambio que se tiene
que hacer, se pasa a la fase de monitoreo y planeacin, si el rendimiento es
9 http://www.monografias.com/trabajos31/metodologia-itil/metodologia-itil.shtml#proceso
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 16
satisfactorio se da la aprobacin del cambio, y en caso de que el rendimiento
sea malo se pasa a la fase de reingeniera hasta que el proceso funcione
adecuadamente, ya que se aprueban los cambio, se construyen prototipos o
modelos en los que se van a hacer las pruebas, se hacen las pruebas
pertinentes para ver las capacidades del sistema, ya que el proceso est
probado se da la autorizacin e implementacin; ya implementado se ve que no
se hayan tenido desviaciones y se ajusta a las necesidades actuales que
tambin se le considera como revisin post-implementacin.
Figura 6: Proceso de control de cambios
1.7.5 PROCESO DE MANEJO DE ENTREGAS
Su objetivo es planear y controlar exitosamente la instalacin de Software y
Hardware bajo tres ambientes: ambiente de desarrollo, ambiente de pruebas
controladas y ambiente real.
Este proceso tiene un diagrama que marca la transicin que se da de acuerdo
a los ambientes por los que se va dando la evolucin del proyecto.
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 17
En lo que respecta al ambiente de desarrollo vemos en la Figura 7 que se tiene
que hacer la liberacin de las polticas, la liberacin de la planeacin, el diseo
lgico de la infraestructura que se va a implementar y la adquisicin de
software y hardware estn entre los ambientes de desarrollo y de pruebas
controladas; ya que se requiere que ambos hagan pruebas sobre ellos; en el
ambiente de pruebas controladas vemos que se hace la construccin y
liberacin de las configuraciones (nivel lgico), se hacen las pruebas para
establecer los acuerdos de aceptacin; se da la aceptacin total de versiones y
de modelos, se arranca la planeacin y finalmente las pruebas y
comunicaciones; y en lo que es el ambiente real vemos que se da la
distribucin e instalacin. 10
En la etapa del ambiente real es la que se ve de forma ms concreta, ya que
muchas veces no tenemos idea de todo lo que pasa hasta antes de la
instalacin.
En el proceso de entrega del servicio es el punto en el que el usuario hace uno
del servicio y no sabe que detrs del servicio que est recibiendo hay un sin fin
de actividades y de decisiones que se tuvieron que tomar para que llegar a este
punto.
Este proceso es en el que ms cuidado debemos de poner, ya que en caso de
haber fallas, el primero en detectarlas o en percibirlas es el usuario, y eso nos
genera que el cliente este insatisfecho o molesto. Por lo general los usuarios no
saben que para que puedan hacer uso de los servicios, se paso por una fase
de planeacin, monitoreo, anlisis y por un sin fin de pruebas, con la intencin
de que en caso de que algo no funcione, se d en la fase de pruebas
controladas y no en la fase de pruebas en ambiente real, donde el mayor
afectado es el cliente.
10
http://www.monografias.com/trabajos31/metodologia-itil/metodologia-itil.shtml#proceso
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 18
Figura 7: Proceso de manejo de entregas
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 19
CAPITULO II
GESTION DE VERSIONES
2.1 Introduccin y Objetivos
La Gestin de Versiones es la encargada de la implementacin y control de
calidad de todo el software y hardware instalado en el entorno de produccin.
La Gestin de Versiones debe colaborar estrechamente con la Gestin de
Cambios y de Configuraciones para asegurar que toda la informacin relativa a
las nuevas versiones se integra adecuadamente en la CMDB de forma que
sta se halle correctamente actualizada y ofrezca una imagen real de la
configuracin de la infraestructura TI.
La Gestin de Versiones tambin debe mantener actualizada la Biblioteca de
Software Definitivo (DSL), donde se guardan copias de todo el software en
produccin, y el Depsito de Hardware Definitivo (DHS), donde se almacenan
piezas de repuesto y documentacin para la rpida reparacin de problemas de
hardware en el entorno de produccin.
Las interacciones y funcionalidades de la Gestin de Versiones se resumen
sucintamente en el siguiente interactivo:
Las complejas interrelaciones entre todos los elementos que componen una
infraestructura TI convierten en tarea delicada la implementacin de cualquier
cambio.
La Gestin de Cambios es la encargada de aprobar y supervisar todo el
proceso pero es tarea especfica de la Gestin de Versiones el disear, poner a
prueba e instalar en el entorno de produccin los cambios preestablecidos.
Todo ello requiere de una cuidadosa planificacin y coordinacin con el resto
de procesos asociados a la Gestin de Servicios TI.
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 20
Entre los principales objetivos de la Gestin de Versiones se incluyen:
Establecer una poltica de implementacin de nuevas versiones de
hardware y software.
Implementar las nuevas versiones de software y hardware en el entorno
de produccin tras su verificacin en un entorno realista de pruebas.
Garantizar que el proceso de cambio cumpla las especificaciones de la
RFC correspondiente.
Asegurar, en colaboracin con la Gestin de Cambios y
Configuraciones, que todos los cambios se ven correctamente reflejados
en la CMDB.
Archivar copias idnticas del software en produccin, as como de toda
su documentacin asociada, en la Biblioteca de Software Definitivo
(DSL).
Mantener actualizado el Depsito de Hardware Definitivo (DHS).
2.2 Beneficios y Dificultades
Los beneficios de una correcta Gestin de Versiones se resumen en:
El proceso de cambio se realiza sin deterioro de la calidad de servicio.
Las nuevas versiones cumplen los objetivos propuestos.
Se reduce el nmero de incidentes por incompatibilidades con otro
software o hardware instalado.
El proceso de pruebas asociado no slo permite asegurar la calidad del
software y hardware a instalar sino que tambin permite conocer la
opinin de los usuarios sobre la funcionalidad y usabilidad de las nuevas
versiones.
El correcto mantenimiento de la DSL impide que se pierdan (valiosas)
copias de los archivos fuente.
Se reduce el nmero de copias de software ilegales.
Control centralizado del software y hardware desplegado.
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 21
Proteccin contra virus y problemas asociados a versiones de software
incontroladas.
Las principales dificultades con las que topa la Gestin de Versiones son:
No existe una clara asignacin de responsabilidades y/o la organizacin
TI no acepta la figura dominante de la Gestin de Versiones en todo el
proceso de implementacin del cambio.
No se dispone de un entorno de pruebas adecuado en donde se puedan
testear de forma realista las nuevas versiones de software y hardware.
Hay resistencia en los diferentes departamentos a la centralizacin del
proceso de cambio. Es habitual que existan reticencias a adoptar
sistemas estandarizados en toda la organizacin, sobre todo cuando
sta no ha sido la poltica tradicional de la misma.
Se realizan cambios sin tener en cuenta a la Gestin de Versiones
argumentado que estos slo son responsabilidad de un determinado
grupo de trabajo o que su "urgencia" requera de ello.
Hay resistencias a aceptar posibles planes de "back-out". Ciertos
entornos de produccin pueden elegir "ignorar" lo problemas que una
nueva versin puede provocar en otras reas y resistirse a volver a la
ltima versin estable.
La implementacin sincronizada de versiones en entornos altamente
distribuidos.
La solucin a estos problemas pasa por:
Un firme compromiso de la organizacin con la Gestin de Versiones y
sus responsables.
Un adecuado plan de comunicacin que informe a todos los
responsables y usuarios de la organizacin TI de las ventajas de una
correcta gestin de todo el proceso de cambio.
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 22
Una versin es un grupo de CIs de nueva creacin o modificados que han sido
validados para su instalacin en el entorno de produccin. Las especificaciones
funcionales y tcnicas de una versin estn determinadas en la RFC
correspondiente.
2.3 Clasificacin de las Versiones
Las versiones pueden clasificarse, segn su impacto en la infraestructura TI,
en:
Versiones mayores: que representan importantes despliegues de
software y hardware y que introducen modificaciones importantes en la
funcionalidad, caractersticas tcnicas, etc.
Versiones menores: que suelen implicar la correccin de varios errores
conocidos puntuales y que a menudo son modificaciones que vienen a
implementar de una manera correctamente documentada soluciones de
emergencia.
Versiones de emergencia: modificaciones que reparan de forma rpida
un error conocido.
Como pueden llegar a existir mltiples versiones es conveniente definir una
referencia o cdigo que los identifique unvocamente. El sistema
universalmente aceptado es:
Versiones mayores: 1.0, 2.0, etc.
Versiones menores: 1.1, 1.2, 1.3, etc.
Versiones de emergencia: 1.1.1, 1.1.2, etc.
Aunque en algunos casos esta clasificacin se refina an ms (vea, por
ejemplo, en la ayuda la versin de su navegador).
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 23
En su ciclo de vida una versin puede encontrase en diversos estados:
desarrollo, pruebas, produccin y archivado.11
En la Figura 8 nos ilustra grficamente la evolucin temporal de una versin:
Figura 8: Evolucin temporal de una versin
El despliegue de nuevas versiones puede realizarse de diferentes maneras y
es responsabilidad de la Gestin de Cambios el determinar la forma ms
conveniente de hacerlo. Entre las opciones ms habituales cabe contar:
Versin delta: slo se testean e instalan los elementos modificados.
Esta opcin tiene como ventaja su mayor simplicidad pero conlleva el
peligro de que puedan aparecer problemas e incompatibilidades en el
entorno de produccin.
Versin completa: Se distribuyen todos los elementos afectados ya
hayan sido modificados o no. Aunque esta opcin es obviamente ms
trabajosa es ms improbable que se generen incidentes tras la
instalacin si se han realizado las pruebas pertinentes.
11
http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/conceptos_basicos_gestion_de_versiones.php
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 24
Paquete de Versiones: La Gestin de Cambios puede optar por
distribuir de forma sincronizada diferentes paquetes de versiones, de
esta forma se ofrece una mayor estabilidad al entorno TI. En algunos
casos esta opcin es obligada por incompatibilidades entre una nueva
versin con software o hardware previamente instalado. Pensemos, por
ejemplo, en la migracin a un nuevo sistema operativo que requiere
hardware ms avanzado y/o nuevos versiones de los programas
ofimticos.
2.4 Visin General
La Gestin de Versiones es la encargada de la implementacin y control de
calidad de todo el software y hardware instalado en el entorno de produccin.
La Gestin de Versiones debe colaborar estrechamente con la Gestin de
Cambios y de Configuraciones para asegurar que toda la informacin relativa a
las nuevas versiones se integra adecuadamente en la CMDB de forma que
sta se halle correctamente actualizada y ofrezca una imagen real de la
configuracin de la infraestructura TI.12
La Gestin de Versiones tambin debe mantener actualizada la Biblioteca de
Software Definitivo (DSL), donde se guardan copias de todo el software en
produccin, y el Depsito de Hardware Definitivo (DHS), donde se almacenan
piezas de repuesto y documentacin para la rpida reparacin de problemas de
hardware en el entorno de produccin.
Las interacciones y funcionalidades de la Gestin de Versiones se resumen
sucintamente en la siguiente Figura 9:
12
http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/conceptos_basicos_gestion_de_versiones.php
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 25
Figura 9: Visin General de la Gestin de Versiones
2.5 Planificacin
Es crucial establecer un marco general para el lanzamiento de nuevas
versiones que fije una metodologa de trabajo. Esto es especialmente
importante para los casos de versiones menores y de emergencia pues en el
caso de lanzamientos de gran envergadura se deben desarrollar planes
especficos que tomen en cuenta las peculiaridades de cada caso.
A la hora de planificar correctamente el lanzamiento de una nueva versin se
deben de tomar en cuenta los siguientes factores:
Cmo puede afectar la nueva versin a otras reas del entramado TI.
Qu CIs se vern directa o indirectamente implicados durante y tras el
lanzamiento de la nueva versin.
Cmo ha de construirse el entorno de pruebas para que ste sea fiel
reflejo del entorno de produccin.
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 26
Qu planes de back-out son necesarios.
Cmo y cundo se deben implementar los planes de back-out para
minimizar el posible impacto negativo sobre el servicio y la integridad del
sistema TI.
Cules son los recursos humanos y tcnicos necesarios para llevar a
cabo la implementacin de la nueva versin con garantas de xito.
Quines sern los responsables directos en las diferentes etapas del
proceso
Qu planes de comunicacin y/o formacin deben desarrollarse para
que los usuarios estn puntualmente informados y puedan percibir la
nueva versin como una mejora.
Qu tipo de despliegue es el ms adecuado: completo, delta,
sincronizado en todas los emplazamientos, gradual, ...
Cul es la vida media til esperada de la nueva versin.
Qu impacto puede tener el proceso de lanzamiento de la nueva versin
en la calidad del servicio.
Si es posible establecer mtricas precisas que determinen el grado de
xito del lanzamiento de la nueva versin.
2.6 Desarrollo
La Gestin de Versiones es la encargada del diseo y construccin de las
nuevas versiones siguiendo las pautas marcadas en las RFCs
correspondientes.
A veces el desarrollo se realizara "en la casa" y muchas otras requerir la
participacin de proveedores externos. En este segundo caso, la tarea de la
Gestin de Versiones ser la de asegurar que el paquete o paquetes de
software o hardware ofrecidos cumple las especificaciones detalladas en la
RFC. Asimismo, la Gestin de Versiones ser la responsable de todo el
proceso de configuracin necesario.
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 27
El desarrollo debe incluir, si esto fuera necesario o simplemente recomendable,
todos los scripts de instalacin necesarios para el despliegue de la versin.
Estos scripts debern tener en cuenta aspectos tales como:
Back-up automtico de datos.
Actualizaciones necesarias de las Bases de Datos asociadas.
Instalacin de las nuevas versiones en diferentes sistemas o
emplazamientos geogrficos.
Creacin de logs asociados al proceso de instalacin.
Parte integrante del desarrollo lo componen los planes de back-out asociados.
Estos tendrn que tomar en cuenta la disponibilidad acordada con los clientes
en los SLAs correspondientes.
2.7 Validacin
Un bien planificado protocolo de tests es absolutamente indispensable para
lanzar al entorno de produccin una nueva versin con razonables garantas de
xito.
Las pruebas no deben limitarse a una validacin de carcter tcnico (ausencia
de errores) sino que tambin deben realizarse pruebas funcionales con
usuarios reales para asegurarse de que la versin cumple los requisitos
establecidos y es razonablemente usable (siempre existe una inevitable
resistencia al cambio en los usuarios que debe ser tenida en consideracin).
Es importante que las pruebas incluyan los planes de back-out para
asegurarnos que se podr volver a la ltima versin estable de una forma
rpida, ordenada y sin perdidas de valiosa informacin.
Las principales actividades realizadas en el proceso de prueba deben incluir:
Pruebas del correcto funcionamiento de la versin en un entorno
realista.
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 28
Pruebas de los procedimientos automticos o manuales de instalacin.
Listas de "bugs" o errores detectados, si se diera el caso.
Pruebas de los planes de back-out.
Documentacin para usuarios y personal de servicio.
La Gestin de Cambios ser la encargada de dar la validacin final a la versin
para que se proceda a su instalacin. Si la versin no fuera aceptada se
devolver a la Gestin de Cambios para su reevaluacin.
2.8 Implementacin
Llego el momento de la verdad: la distribucin de la nueva versin, tambin
conocida como rollout.
El rollout puede ser de varios tipos:
Completo y sincronizado: se realiza de manera integral y simultnea
en todos los emplazamientos.
Fragmentado: ya sea bien espacial o temporalmente. Por ejemplo,
introduciendo la nueva versin por grupos de trabajo o incrementando
progresivamente la funcionalidad ofrecida.
El procedimiento de rollout debe ser cuidadosamente documentado para que
todas las partes conozcan sus tareas y responsabilidades especficas. En
particular los usuarios finales deben estar puntualmente informados del
calendario de lanzamiento y de cmo este puede afectar a sus actividades
diarias.
Es imprescindible determinar claramente:
Los CIs que deben borrarse e instalarse y en que orden debe realizarse
este proceso.
Cundo debe realizarse este proceso para diferentes grupos de trabajo
y/o localizaciones geogrficas.
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 29
Que mtricas determinan la puesta en marcha de los planes de back-out
y si estos deben ser completos o parciales.
Tras la distribucin la Gestin de Versiones debe asegurarse de que:
Se incluya una copia de la versin en la DSL.
El DHS incorpore repuestos funcionales de los nuevos CIs.
La CMDB est correctamente actualizada.
Los usuarios estn debidamente informados de las nuevas
funcionalidades y han recibido la formacin necesaria para poder sacar
el adecuado provecho de las mismas.
Tras la implementacin, la Gestin de Versiones debe ser puntualmente
informada por el Service Desk de los comentarios, quejas, incidentes, etc. que
la nueva versin haya podido suscitar. Toda esta informacin deber ser
analizada para asegurar que las prximas versiones incorporen las sugerencias
recibidas y que se tomen las medidas correctivas necesarias para minimizar el
impacto negativo que puedan tener futuros cambios.
2.9 Comunicacin y Formacin
Es frecuente, y a su vez un grave error, que cuando se aborden cuestiones de
carcter tcnico se obvie el factor humano.
Salvo contadas excepciones, es necesaria la interaccin usuario-aplicacin y
sta suele representar el eslabn ms dbil de la cadena.
Es intil disponer de un sofisticado servicio TI si los usuarios , debido a una
incompleta (in)formacin, no se encuentran en disposicin de aprovechar sus
ventajas.
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 30
La (in)formacin debe estructurarse en distintos niveles:
Los usuarios deben conocer el prximo lanzamiento de una nueva
versin y conocer con anterioridad la nueva funcionalidad planificada o
los errores que se pretenden resolver para participar, a su discrecin, en
el proceso.
Siempre que sea posible las pruebas de carcter funcional deben ser
realizadas por un selecto grupo de usuarios finales. Durante este
proceso de prueba se documentarn y analizarn:
o La experiencia subjetiva de usuario.
o Los comentarios y sugerencias sobre usabilidad y funcionalidad. o
Las dudas que hayan surgido durante el uso de la nueva versin.
o La claridad de la documentacin que se pondr a disposicin del
usuario final.
Cuando se considere oportuno se impartirn cursos presenciales o
remotos mediante mdulos de e-learning sobre el funcionamiento de la
nueva versin.
Se desarrollar una pgina de FAQs donde los usuarios puedan aclarar
las dudas ms habituales y puedan solicitar ayuda o soporte tcnico en
el uso de la nueva versin.
2.10 Control de Proceso
Es imprescindible elaborar informes que permitan evaluar el rendimiento de la
Gestin de Versiones.
Para que estos informes ofrezcan una informacin precisa y de sencilla
evaluacin es necesario elaborar mtricas de referencia que cubran aspectos
tales como:
Nmero de lanzamientos de nuevas versiones.
Nmero de back-outs y razones de los mismos.
Incidencias asociadas a nuevas versiones.
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 31
Cumplimientos de los plazos previstos para cada despliegue.
Asignacin de recursos en cada caso.
Correccin y alcance de la CMDB y la DHS.
Existencia de versiones ilegales de software.
Adecuado registro de las nuevas versiones en la CMDB.
Incidencias provocadas por uso incorrecto (formacin inadecuada) de la
nueva versin por parte de los usuarios.
Disponibilidad del servicio durante y tras el proceso de lanzamiento de la
nueva versin.
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 32
CAPITULO 3
CONTROL DE VERSIONES
3.1 Que es un Control de Versiones
Una versin, revisin o edicin de un producto, es el estado en l se encuentra
en un momento dado en su desarrollo o modificacin. Se llama control de
versiones a la gestin de los diversos cambios que se realizan sobre los
elementos de algn producto o una configuracin del mismo. Los sistemas de
control de versiones facilitan la administracin de las distintas versiones de
cada producto desarrollado, as como las posibles especializaciones realizadas
(por ejemplo, para algn cliente especfico).
El control de versiones se realiza principalmente en la industria informtica para
controlar las distintas versiones del cdigo fuente. Sin embargo, los mismos
conceptos son aplicables a otros mbitos como documentos, imgenes, sitios
web, etctera.13
Aunque un sistema de control de versiones puede realizarse de forma manual,
es muy aconsejable disponer de herramientas que faciliten esta gestin (CVS,
Subversion, SourceSafe, ClearCase, Darcs, Plastic SCM, Git, Mercurial, etc.).
3.1.1 Caractersticas
Un sistema de control de versiones debe proporcionar:
Mecanismo de almacenaje de los elementos que deba gestionar (ej.
archivos de texto, imgenes, documentacin...)
Posibilidad de realizar cambios sobre los elementos almacenados (ej.
modificaciones parciales, aadir, borrar, renombrar o mover elementos)
13
http://macprogramadores.org/tutoriales/tutoriales/cvssvn.pdf
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 33
Registro histrico de las acciones realizadas con cada elemento o
conjunto de elementos (normalmente pudiendo volver o extraer un
estado anterior del producto)
Aunque no es estrictamente necesario, suele ser muy til la generacin de
informes con los cambios introducidos entre dos versiones, informes de estado,
marcado con nombre identificativo de la versin de un conjunto de ficheros,
etctera.
3.1.2 Clasificacin
La principal clasificacin que se puede establecer est basada en el
almacenamiento del cdigo:
Centralizados: existe un repositorio centralizado de todo el cdigo, del
cual es responsable un nico usuario (o conjunto de ellos). Se facilitan
las tareas administrativas a cambio de reducir la potencia y flexibilidad,
pues todas las decisiones fuertes (como crear una nueva rama)
necesitan la aprobacin del responsable. Algunos ejemplos son CVS y
Subversion
Distribuidos: se aumenta la capacidad de decisin distribuida. Esto da
ms flexibilidad pero puede dificultar bastante la sincronizacin.
Ejemplos: GIT y GNU Arch
3.1.3 Funcionamiento
Todos los sistemas de control de versiones se basan en disponer de un
repositorio, que es el conjunto de informacin gestionada por el sistema. Este
repositorio contiene el historial de versiones de todos los elementos
gestionados.
Cada uno de los usuarios puede crearse una copia local duplicando el
contenido del repositorio para permitir su uso. Es posible duplicar la ltima
versin o cualquier versin almacenada en el historial. Este proceso se suele
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 34
conocer como check out o desproteger. Para modificar la copia local existen
dos semnticas bsicas:
Exclusivos: para poder realizar un cambio es necesario marcar en el
repositorio el elemento que se desea modificar y el sistema se encargar
de impedir que otro usuario pueda modificar dicho elemento.
Colaborativos: en el que cada usuario se descarga la copia la modifica
y el sistema automticamente mezcla las diversas modificaciones. El
principal problema es la posible aparicin de conflictos que deban ser
solucionados manualmente o las posibles inconsistencias que surjan al
modificar el mismo fichero por varias personas no coordinadas. Adems,
esta semntica no es apropiada para ficheros binarios.
Tras realizar la modificacin es necesario actualizar el repositorio con los
cambios realizados. Habitualmente este proceso se denomina commit, check in
o proteger.
3.2 DSL (Definitive Software Library)
La Biblioteca de Software Definitivo (DSL) debe contener copia de todo el
software instalado en el entorno TI. Esto incluye no solo sistemas operativos y
aplicaciones sino tambin controladores de dispositivos y documentacin
asociada.
La DSL debe contener el histrico completo de versiones de un mismo software
para proporcionar la versin necesaria en caso de que se deban implementar
los planes de back-out.14
La DSL debe ser almacenada en un entorno seguro y es conveniente que se
realicen back-up peridicos.
14
http://macprogramadores.org/tutoriales/tutoriales/cvssvn.pdf
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 35
3.3 DHS (Depsito de Hardware Definitivo)
El Depsito de Hardware Definitivo (DHS) contiene piezas de repuesto para los
CIs (Configuration Items) en el entorno de produccin.
Los activos almacenados deben incorporarse a la CMDB (Database Change &
Configuration Management) en el caso de que los CIs correspondientes se
hallen registrados en la misma (esto puede depender del alcance y nivel de
detalle de la CMDB).
Las principales actividades de la Gestin de Versiones se resumen en:
Establecer una poltica de planificacin para la implementacin de
nuevas versiones.
Desarrollar o adquirir de terceros las nuevas versiones.
Poner a prueba las nuevas versiones en un entorno que simule lo mejor
posible el entorno de produccin.
Validar las nuevas versiones.
Implementar las nuevas versiones en el entorno de produccin.
Llevar a cabo los planes de back-out o retirada de la nueva versin si
esto fuera necesario.
Actualizar la DSL, el DHS y la CMDB.
Comunicar y formar a los clientes y usuarios sobre las funcionalidades
de la nueva versin.
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 36
CAPITULO IV
ESTRUCTURA UN GESTOR DE VERSIONES
4.1 Introduccin
Los gestores de versiones (version control system), tambin llamados
herramientas de gestin de configuraciones software o repositorios, son
herramientas que permiten a los programadores de un proyecto centralizar y
coordinar sus trabajos. Los gestores de versiones son especialmente tiles
para todo tipo de documentos que sean revisados frecuentemente, como
pueda ser el cdigo fuente de un programa, su documentacin, cartas, etc...
Normalmente uno de los programadores va a ser el administrador del gestor de
versiones, que es el que se encargara de administrar y dar permisos en el
gestor de versiones, aunque esta tarea se puede tambin delegar en una
persona especializada en la administracin de sistemas informticos.
Aunque los gestores de versiones estn pensados para grupos de trabajo,
tambin son muy tiles para un programador individual, ya que le ayuda a
llevar una cuenta histrica de las diferentes versiones de sus ficheros.
En el mundo de UNIX se han utilizado ampliamente cuatro programas para
gestin de versiones:
RCS (Revision Control System). El ms antiguo de todos, y que adems
tiene su cdigo fuente publicado de forma gratuita por la Free Software
Foundation. Prcticamente todos los sistemas UNIX lo tienen, y Mac OS X
tambin lo trae preinstalado.
SCCS (Source Code Control System). Fue introducido por AT&T en el
Sistema V de UNIX, y actualmente forma parte del estndar X/Open. Sin
embargo Mac OS X no lo trae preinstalado, y nosotros no lo
estudiaremos.
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 37
CVS (Concurrent Version System). Est basado en ReS, y actualmente
es el gestor de versiones ms utilizado por los desarrolladores de software
libre en Internet.
Subversin. Es el resultado de un reingeniera sobre los conceptos de evs
para buscar una solucin alternativa a los problemas ms comunes con lo
que se encuentran los usuarios de evs. Actualmente, su volumen de
usuarios est creciendo rpidamente.
En este documento estudiaremos evs y Subversin. Aunque usaremos Mac OS
X para todos los ejemplos, su interoperatividad hace que las explicaciones
puedan ser aplicadas sin problemas en otros entornos UNIX o Windows.
4.2 Porqu usar un repositorio
Los proyectos de desarrollo de software implican tener a varios desarrolladores
trabajando de forma concurrente sobre varios conjuntos de ficheros que con
frecuencia se solapan. En consecuencia resulta fundamental poder trazar los
cambios hechos por los programadores, de forma que siempre sepamos quin
es el responsable de cada cambio. Para ello los gestores de versiones
mantienen un sistema de logs. Adems los gestores de versiones siempre nos
permiten deshacer los cambios para ir a un estado anterior. Tambin es
importante que el gestor de versiones permita mezclar 105 cambios realizados
por 105 distintos programadores. Los principales argumentos a favor de usar
un gestor de versiones son:
Persistencia. Manteniendo un histrico de revisiones desaparece el
problema de perder un cdigo cuando se modifica. Adems mantener el
cdigo del proyecto centralizado ayuda a realizar copias de seguridad.
Integracin. La integracin se realiza implcitamente segn los
programadores guardan sus contribuciones en el repositorio.
Contabilidad. Es importante saber quin y cundo se ha realizado cada
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 38
cambio en el proyecto. El gestor de versiones permite guardar un histrico
de quin ha realizado cada cambio junto con comentarios que los propios
programadores guardan indicando el motivo del cambio.
Branching. Un mismo cdigo se puede utilizar en varios proyectos con slo
hacer pequeas modificaciones. Los gestores de versiones permiten crear una
lnea base llamada tronco (trunk) y varias ramas (branches) de un cdigo
fuente. Adems, el gestor de versiones ayuda a combinar el contenido de las
ramas con el tronco. Por ejemplo, un proyecto puede tener un tronco de
desarrollo, y una o ms ramas para mantenimiento de errores en versiones
release antiguas. Esto evita el quebradero de cabeza de tener que mantener
sincronizadas varias versiones similares de un cdigo fuente.
Trabajo distribuido. Los gestores de versiones modernos permiten
almacenar el cdigo fuente en un repositorio al que programadores de
distintas partes del mundo se conectan a travs de Internet.
4.3 Revisiones, versiones release y variantes
Los gestores de versiones mantienen una copia de todos los ficheros que
guardamos en el repositorio a lo largo del ciclo de vida del proyecto, de forma
que en cualquier momento podemos "dar marcha atrs" y recuperar una
versin que tenamos guardada. 15
Para ello a las diferentes versiones se las da un nmero de versin, al que
llamaremos revisin, que nos sirve para identificar luego cada versin que
hayamos guardado. Aunque muchas veces en la literatura a las revisiones
tambin se las llama versiones, nosotros usaremos el trmino revisiones para
evitar confusiones innecesarias.
Conviene diferenciar entre versiones release de un programa y revisiones. Las
15
http://macprogramadores.org/tutoriales/tutoriales/cvssvn.pdf
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 39
versiones release son versiones que se sacan al pblico cuando conseguimos
tener el programa en un estado estable, mientras que las revisiones son las
que crea el programador cuando al final del da decide guardar su trabajo en el
repositorio. Es decir, no tenga miedo de guardar tantas revisiones como quiera.
Por ltimo conviene comentar que el trmino variante se utiliza para referirnos
a varias versiones que coexisten en un mismo instante de tiempo (p.e. para
distintos sistemas operativos).
4.4 Modelos de configuracin
Se llama modelo de configuracin a la forma de organizar los ficheros que
componen un proyecto y a la forma de darles nombre. El modelo de
configuracin es el producto cartesiano de dos espacios, el espacio de
producto y el espacio de reversiones:
El espacio de producto son los ficheros que componen el proyecto y las
relaciones entre ellos, las cuales pueden ser de dos tipos: Composicin, donde
un fichero est formado por otros (p.e. las relaciones include), y dependencia
donde el contenido de un fichero depende de otro fichero.
El espacio de reversiones muestra la evolucin de un fichero a lo largo del
tiempo.
Los gestores de versiones estn pensados para que almacenen las diferentes
revisiones de un fichero de forma eficiente, es decir, slo almacenan los
cambios realizados a cada fichero, no todo el fichero. Se llama delta a la
diferencia entre dos revisiones, y los deltas se pueden representar de dos
formas 16
16
http://macprogramadores.org/tutoriales/tutoriales/cvssvn.pdf
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 40
1. Representacin simtrica donde dadas dos revisiones de un fichero T1
y T2, se almacenan las lneas de texto que estn en T1 y no estn en T2, y
las que estn en T2 y no estn en T1 (vase Figura 1.1), es decir, se
almacena que lneas de texto estn en cada versin y no en la otra.
2. Representacin por cambios. Donde se almacenan los cambios que
hay que hacer para pasar de T1 a T2.
4.5 Versionado extensional e intencional
A la hora de asignar versiones a los ficheros se suelen utilizar en paralelo dos
tcnicas de versionado:
El ms conocido y normal es el versionado extensional (por aadidos), donde
se va numerando el contenido de cada fichero segn evoluciona, es decir, los
cambios que vamos haciendo al fichero en las distintas revisiones.
El otro tipo de versionado es el versionado intensional (que significa dividir en
partes), el cual nos permite que de una configuracin del software haya varias
variantes, y al acceder a la herramienta de gestin de versiones indicamos qu
versin es la que queremos coger (p.e. Xll para Linux, Cocoa para Mac OS X, o
Win32 para Windows). Este versionado es muy tpico gestionarlo con directivas
del propio lenguaje como por ejemplo de C.
4.6 Gestores de versiones orientados a ficheros y a proyectos.
En funcin de la forma en que se asignan revisiones, existen dos tipos de
gestores de versiones. Los gestores de versiones orientados a ficheros (p.e.
CVS), donde los nmeros de revisin se asignan para cada fichero de forma
individual, y los gestores de versiones orientados a proyectos (p.e.
Subversin), donde el nmero de revisin se asigna a todos los ficheros que
componen el proyecto en un momento dado.
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 41
La Figura 1.2 muestra un ejemplo de nmeros de revisin asignados a los
ficheros de un proyecto en un momento dado, en el caso de CVS. Como
vemos, cada fichero tiene un nmero de revisin distinto, que corresponde con
el nmero de veces que se ha modificado y guardado el fichero en el
repositorio. 17
Las revisiones de nmero ms alto de cada fichero corresponden al estado
actual del proyecto. En los repositorios orientados a ficheros, como cada
fichero crece de forma independiente, es comn realizar el tagging, que
consiste en etiquetar las revisiones que tienen los ficheros en un momento
dado, con el fin de poder recuperar ms tarde ese estado. En CVS se puede
usar la etiqueta especial HEAD para referirse las ltimas revisiones de todos
los ficheros del proyecto.
Figura 10. Ejemplo de repositorio orientado a ficheros
17
http://macprogramadores.org/tutoriales/tutoriales/cvssvn.pdf
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 42
CAPITULO V
ELEMENTOS DEL REPOSITORIO
5.1 Interaccin con el repositorio
Normalmente se llama repositorio a un directorio situado en una mquina (que
acta como servidor) donde se almacenan uno o ms proyectos. Por cada
proyecto se suele crear un subdirectorio dentro del directorio de repositorio que
contiene los ficheros del proyecto. A este directorio se le llama directorio de
proyecto. El repositorio puede estar situado en la misma mquina que el
programador, pero es ms comn colocar en repositorio en una mquina
distinta y conectarse al repositorio a travs de Internet siguiendo el modelo
cliente servidor.
Los desarrolladores actan como clientes, y suelen bajarse una copia de uno o
ms proyectos a directorios de su mquina de trabajo. A la copia de un
proyecto se la llama sandbox (nomenclatura CVS), o working copy
(nomenclatura Subversion). Tanto en CVS como en Subversion existe una
nomenclatura homognea para las operaciones que puede realizar el
programador con su sandbox respecto al proyecto, que son las siguientes:
1. Import. Es la operacin de crear un proyecto en el respositorio a partir de
unos ficheros situados en un directorio de la mquina local. Esta operacin
suele realizarse slo una vez al principio de un proyecto.
2. Checkout. Es la operacin de bajarse un proyecto desde el repositorio a un
directorio de la mquina local. Este directorio es el sandbox, y adems de
los ficheros del proyecto, contiene algunos ficheros con metadatos que
sirven al gestor de versiones para conocer informaciones como los logs o
las revisiones de un fichero. Esta operacin la realiza normalmente slo una
vez cada programador que va a trabajar contra un proyecto almacenado en
un repositorio.
3. Export. Es una operacin parecida a checkout, pero en vez de estar
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 43
destinada a programadores que desean crearse una sandbox, est
destinada a usuarios que quieren bajarse el cdigo fuente sin ficheros
adicionales de metadatos. Es decir, con la operacin export, el usuario no
obtiene un sandbox, sino slo un directorio con los ficheros del proyecto
listos para ser compilados.
4. Commit. Una vez que el desarrollador modifica uno o ms ficheros del
proyecto, ste debe subir los cambios al proyecto del repositorio usando la
operacin de commit. Cuando se hace un commit tanto CVS como
Subversion piden introducir un mensaje con una descripcin de los cambios
realizados.
S. Update. Cuando un programador actualiza el proyecto, los dems
desarrolladores pueden bajarse estos cambios utilizando la operacin de
update.
Los gestores de versiones permiten que un programador modifique su sandbox
y, sin necesidad de hacer un commit de los cambios, ejecute la operacin de
update. En este caso el gestor de versiones es lo suficientemente inteligente
como para actualizar en el sandbox slo las lneas de cdigo cambiadas en el
proyecto del repositorio.
Cuando un programador empieza a trabajar con un gestor de versiones suele
empezar teniendo bastante miedo a que un update le estropee su cdigo: No
tenga ningn miedo a realizar las operaciones commit y update con tanta
frecuencia como sea necesario (incluso cuanto ms frecuentemente lo haga
mejor) y no se preocupe si otros programadores estn tambin modificando el
proyecto del repositorio. Los gestores de versiones son lo suficientemente
inteligentes como para no destrozar su cdigo. En la seccin 2 veremos que a
veces se pueden producir conflictos, pero que su resolucin es ms sencilla de
lo que pueda parecer.
En cualquier caso, y como regla general, se recomienda seguir el siguiente
paradigma de interaccin con el proyecto del repositorio:
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 44
La operacin de update la puede realizar tantas veces como quiera. Por
ejemplo la puede realizar todos los das por la maana antes de ponerse a
trabajar en su proyecto, o despus de venir de comer. Si su cdigo
compilaba antes del update, deber seguir compilando despus del update.
Si no es as puede usar las herramientas de logs que proporciona el gestor
de versiones para identificar quin ha subido el cambio, y vaya a hablar con
l inmediatamente. Si en su grupo de trabajo es frecuente que el cdigo
deje de compilar correctamente despus de hacer un update, es un sntoma
de que una o ms personas en su grupo de trabajo no son muy
competentes.
La operacin de commit se debe realizar slo inmediatamente despus de
hacer un update, y slo cuando se dispone de un cdigo que compila y ejecuta
correctamente. La primera condicin garantiza que si otro programador ha
actualizado el proyecto del repositorio los cambios del otro programador sean
consistentes con los que usted ha realizado. De hecho, los gestores de
versiones impiden realizar un commit cuando hay cambios en el proyecto del
repositorio que no se han bajado al sandbox con update. La segunda condicin
garantiza que los dems programadores no se encuentren con un proyecto con
cdigo que ni siquiera compila: Un sntoma claro de que el gestor de versiones
no se est usando correctamente. Tenga en cuenta que tampoco es
conveniente que los periodos de commit se alarguen demasiados: Cuando ms
se alarguen los periodos de commit, ms trabajo se perder si su mquina falla.
Cuando se hace commit, el gestor de versiones pide un comentario textual que
explique los cambios que se han realizado. Es muy comn que el programador
utilice mensajes poco significativos en estos comentarios, los cuales recuden
considerablemente su utilidad. Es muy importante que utilice mensajes
informativos que puedan ser luego interpretados por otros programadores.
Entre los aspectos que debera incluir este mensaje estn: Por qu se ha
hecho el cambio, qu funcionalidad se ha aadido, cambiado, y eliminado. Por
ltimo conviene comentar que un error comn por parte de los recin llegados
ITIL: GESTION DE VERSIONES
Investigador: Mara 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 slo deben de
almacenarse los ficheros de cdigo fuente (p.e .. e, .h, Makefile) que sirven
para generar el programa, as como los ficheros de documentacin (p.e. . doe, .
ppt), pero no deberamos de almacenar los ficheros que se producen durante la
generacin del programa, como los. 0, los .lib, los. dll o los. exe. Estos ficheros
hacen crecer mucho el tamao del repositorio, y no tiene sentido almacenarlos
ya que siempre se pueden generar a partir de los ficheros de cdigo fuente. En
general, los ficheros de proyecto que crean muchas herramientas de desarrollo
tampoco se deben de guardar en el repositorio ya que estos ficheros contienen
paths que dependen de la mquina donde se site el sandbox. Los ficheros
Makefile o Ant son una excepcin a esta regla siempre que se diseen de
forma que no dependan de rutas absolutas. En el caso de que nuestro proyecto
utilice ficheros de ejemplo, como imgenes. jpg, o vdeos . mpg, estos tambin
se pueden almacenar en un directorio destinada a iconos o casos de prueba.
5.2 Resolucin de conflictos
Tanto CVS como Subversin siguen el paradigma de que varios
programadores pueden modificar concurrentemente los ficheros del proyecto y
despus el gestor de versiones se encarga de realizar la mezcla de ficheros.
Otros gestores de versiones como Microsoft Visual SourceSafe siguen un
paradigma de bloqueos, donde un programador cuando va a codificar un
fichero, primero lo bloquea, luego lo modifica, y luego libera el bloqueo.
Los gestores de versiones realizan la mezcla de ficheros de texto lnea a lnea.
Si 105 cambios estn en diferentes lneas, el sistema aade, reemplaza o
elimina lneas segn proceda. La operacin de mezcla ser satisfactoria
siempre que dos programadores no hayan modificado la misma lnea. En caso
de que ambos hayan modificado la misma lnea se producir un conflicto (a no
ser que hayan modificado exactamente las mismas lneas con el mismo
contenido).
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 46
En teora la operacin de mezcla podra realizarse tanto en la operacin de
commit como en la operacin de update, pero debido a que los gestores de
versiones impiden realizar un commit cuando hay cambios en el proyecto del
repositorio (es decir, cuando nuestra revisin del sandbox es ms antigua que
la del proyecto del repositorio), la operacin de mezcla siempre se realiza
durante el update. Tngase en cuenta que la operacin de mezcla siempre se
realiza entre un fichero en el proyecto del repositorio y otro en el sandbox, y el
resultado de la mezcla siempre acaba depositndose en el sandbox.
Cuando nos encontramos un conflicto, para resolver el conflicto el gestor de
versiones nos muestra dos ficheros: el fichero con los cambios que hemos
hecho en el sandbox, y el fichero con los cambios que otro programador hizo
en el proyecto del repositorio, y se nos seala la o las lneas conflictivas. En
este momento debemos indicar cul de las dos lneas es la correcta (para lo
cual, si tenemos dudas, podemos consultar al otro programador). Una vez
indicado cul es la lnea o lneas correctas, obtendremos en el sandbox el
fichero actualizado y con los cambios aplicados. En este momento podremos
evaluar si todo compila y ejecuta correctamente, y subir 105 cambios al
proyecto del repositorio con la operacin de commit.
5.3 Tagging
Aunque poder obtener la ltima revisin de 105 ficheros de un proyecto en el
repositorio es til, tambin es muy til poder obtener los ficheros del proyecto
en la revisin en la que se encontraban en algn hito pasado (p.e. en la versin
1.0 del proyecto). El tagging permite poner una etiqueta a los ficheros del
proyecto tal como se encuentran en un momento dado por si en el futuro
quisiramos obtener est configuracin.
En el caso de CVS, como muestra la Figura 1.2, a los ficheros se les asigna
nmeros de revisin de forma individual, con lo que el tagging se realiza
poniendo la misma etiqueta a cada fichero en su nmero de revisin actual. Por
su parte, Subversin implementa el tagging mediante copias ligeras (cheap
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 47
copies), que consiste en hacer una copia del proyecto (que normalmente est
en un directorio llamado trunk) en otro directorio (que normalmente estar
metido dentro del directorio tags).
Subversion no asigna nmeros de revisin de forma individual a cada fichero,
sino que por cada revisin que guardamos en el proyecto del repositorio asigna
un nmero de revisin para todos los ficheros del proyecto. Cuando en
Subversion hacemos una copia ligera, no estamos copiando el contenido del
fichero (en la revisin actual y en todas las anteriores) sino que slo estamos
apuntando al contenido de la revisin actual en otra ruta. Esto permite que el
tagging no consuma muchos recursos. Debido a que las copias ligeras son un
puntero a una revisin, slo pueden hacerse copias ligeras de todos los
ficheros del proyecto.
Las estrategias de tagging son muy diversas, pero momentos tpicos en los que
se hace tagging del proyecto son: Cuando se cumple un hito, cuando se
termina una versin release del proyecto, antes de empezar a eliminar una
funcionalidad, o antes de empezar a modificar la forma en que est
implementada una parte del proyecto.
5.4 Branching
A la lnea principal de desarrollo normalmente se la llama tronco (trunk). El
branching consiste en crear una o ms lneas de desarrollo distintas a las que
se llama ramas (branches).
Existen varias razones para crear una rama: Una razn muy usada es para
mantenimiento y correccin de errores de una versin release del producto
mientras que el tronco se utiliza para aadir nueva funcionalidad. Otra razn es
crear una rama para hacer cambios experimentales o reingeniera de cdigo
que en el futuro se podrn aadir o no al tronco de la aplicacin.
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 48
El gestor de versiones construye la rama y el tronco a partir de las mismas
revisiones de Cdigo, hasta que llegado un cierto punto, llamado base de la
rama, el gestor de versiones almacena los cambios en el tronco y en la rama
de forma separada.
En general, deberamos saber que conviene crear una rama antes de empezar
a modificar el cdigo, pero en ocasiones no se decide que conviene crear una
rama hasta que el cdigo ha empezado a ser modificado, en este caso
podemos hacer un branching retroactivo, pero hacer un branching retroactivo
siempre es ms complicado que si desde el principio se decide empezar a
trabajar en otra rama.
En Subversin la rama debe de incluir todos los ficheros del proyecto. Por
contra CVS permite que la rama slo incluya uno o ms ficheros, pero
experimentalmente se sabe que siempre que se va a crear una rama, es mejor
incluir todos los ficheros del proyecto. En caso contrario es muy comn que
acabe necesitndose incluir nuevos ficheros en la rama lo cual complica su
mantenimiento. 18
5.4.1 Nmeros de revisin
Tanto CVS como Subversin asignan un nmero diferente a cada revisin que
almacenamos en el proyecto del repositorio, pero la forma de numerar las
revisiones difiere en dos aspectos:
El primer aspecto es que, como adelantamos en el apartado 6 del Tema 1,
Subversin es orientado a proyecto, es decir, asigna un mismo nmero de
revisin a todos los ficheros que componen el proyecto en un momento dado,
mientras que CVS es orientado a fichero, es decir, tal como muestra la Figura
1.2, a cada fichero se le va asignando nmeros de revisin distintos.
18
http://macprogramadores.org/tutoriales/tutoriales/cvssvn.pdf
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 49
El segundo aspecto a destacar es que Subversin utiliza nmeros consecutivos
para cada revisin que se guarda en el proyecto del repositorio,
independientemente de si la revisin corresponde al tronco o a una rama. En la
Figura 11(a) vemos que los nmeros de revisin en el tronco y en la rama no
tienen porque ser consecutivos.
Sin embargo, como muestra la Figura 11 (b), CVS asigna nmeros de revisin
compuestos por varios nmeros separados por punto. En el caso del tronco el
nmero de revisin suele1 empezar por 1, y despus le sigue el nmero de
revisin del tronco. En el caso de las ramas, las ramas estn formadas por tres
dgitos. Los dos primeros dgitos indican la base de la rama, y el tercero es un
nmero par que indica el nmero de rama para esa revisin. Por ltimo el
cuarto dgito se destina a indicar el nmero de revisin para una rama.
En cualquier caso la forma en que un gestor de versiones asigna nmeros a las
revisiones debe ser vista de forma transparente por parte del usuario, es decir,
no se preocupe por qu nmero de revisin le corresponde a cada revisin que
guarde. Si le interesa recordar una revisin por algn motivo, utilice tagging. 19
Figura 11.(a)Branching
Figura 11.(b) Branching en supervisin
19
http://macprogramadores.org/tutoriales/tutoriales/cvssvn.pdf
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 50
5.4.2 Mezclar ramas
Podemos hacer una operacin de mezcla consistente en aplicar una rama al
tronco, en cuyo caso aplicamos los cambios que h3ya sufrido la rama, durante
las revisiones de sta, a la revisin ms reciente del tronco. Cundo esta
mezcla es deseable, depende de la finalidad para la que se cre la rama: Si es
una rama de mantenimiento y correccin de errores, seguramente sea
deseable hacer esta mezcla. Tambin podra ser interesante aplicar esta
mezcla si la rama se cre para desarrollar un cdigo experimental o para hacer
reingeniera de cdigo, y el trabajo realizado en la rama fue satisfactorio.
1 Es posible crear varios troncos para un mismo fichero, en cuyo caso el
nmero empezara por 2, 3, etc, pero es algo que no se recomienda y no
vamos a estudiar aqu. Es decir, el primer dgito indica el nmero de tronco.
2 Puede crearse una rama de una rama, pero crear ramas anidadas es algo
que tampoco se recomienda por la complejidad que introduce.
Tambin es posible aplicar un tronco a una rama, en cuyo caso aplicamos los
cambios que ha sufrido el tronco a la revisin ms reciente de la rama.
5.4.3 Estrategias de branching
En general el tronco representa la principal lnea de desarrollo del proyecto,
todas las variantes deberan almacenarse en ramas. El principal problema
surge a la hora de decidir si el tronco debera mantener cdigo estable o si el
mantenimiento y reparacin de errores debera realizarse en las ramas. Esto da
lugar a las dos principales estrategias de branching que vamos a comentar a
continuacin: Troncos estables y troncos inestables.
5.4.4 Troncos estables
La estrategia de troncos estables dice que el tronco debera mantener cdigo
que est siempre listo para release. Las ramas se usan para desarrollo,
introducir nueva funcionalidad experimental, para refactorizacin de cdigo, etc.
ITIL: GESTION DE VERSIONES
Investigador: Mara Eugenia Bravo Campoverde Pagina 51
La variante ms estricta de esta estrategia dice que nada debe de mezclarse
en el tronco hasta que no haya pasado por un proceso de aseguramiento de
calidad.
En el caso del cdigo fuente abierto, la estrategia de troncos estables es la ms
popular, ya que cualquier usuario puede bajarse en cualquier momento el
cdigo de nuestro proyecto del repositorio, compilarlo, y todo le debera de
funcionar.
Otra variante menos estricta dice que el cdigo se enva al tronco una vez
acabado (lo que se suele llamar versin beta o release candidate), y en este
momento se crea una rama de aseguramiento de calidad, que es la rama de la
que saldr la versin release del producto. A partir del momento en que
saquemos la versin release del producto, se crea una rama de mantenimiento,
en la que se corrigen posibles errores que surjan ms adelante en la versin
publicada.
Las ventajas de esta estrategia son que siempre tenemos cdigo estable en el
tronco, y que si los desarrollos que hacemos en una rama acaban retrasndose
indefinidamente o no terminan de funcionar, no tenemos que deshacer los
cambios que haya sufrido el tronco.
La principal desventaja de la estrategia de troncos estables es que el cdigo de
la rama puede diferir bastante del cdigo del tronco, con lo que la mezcla con el
tronco la debe de realizar una persona que conozca bien los cambios que se
han desarrollado en la rama.
5.4.5 Troncos inestables
En esta estrategia, el tronco se utiliza para ir guardando las ltimas version