3. Objetivos
❏ Trabajo concurrente y en equipo del equipo de
desarrollo.
❏ Verificar y realizar pruebas de software.
❏ Conseguir incrementos de funcionalidades por
entregables de desarrollo.
❏ Corrección de errores con el mínimo impacto.
4. Control de versiones
Sistema que registra los cambios realizados sobre
un archivo o conjunto de archivos a lo largo del
tiempo.
Fuente: http://git-scm.com/
5. Control de versiones
Un sistema de control de versiones debe
proporcionar:
❏ Mecanismo de almacenamiento de los elementos que deba gestionar.
❏ Posibilidad de realizar cambios sobre los elementos almacenados.
❏ Registro histórico de las acciones realizadas con cada elemento o conjunto de
elementos.
6. Definiciones
❏ Repositorio. Lugar en el que se almacenan los datos actualizados e
históricos de cambios.
❏ Revisión. Es una versión determinada de la información que se gestiona.
❏ Línea base. Revisión aprobada de un documento o fichero fuente, a partir
del cual se pueden realizar cambios subsiguientes.
❏ Branch: Un módulo puede ser branched o bifurcado en un instante de
tiempo de forma que, desde ese momento en adelante se tienen dos
copias (ramas)
7. Definiciones
❏ Branch: Un despliegue crea una copia de trabajo local desde el
repositorio.
❏ Commit: Un commit sucede cuando una copia de los cambios hechos a
una copia local es escrita o integrada sobre repositorio.
❏ Merge: Una integración o fusión une dos conjuntos de cambios sobre un
fichero o un conjunto de ficheros en una revisión unificada de dicho fichero
o ficheros.
9. Flujos de actividades
Trabajo concurrente y en equipo del equipo de
desarrollo.
1. Ramas por características o por historias de usuarios según la metodología que se
utilice.
2. Creación de ramas de desarrollo partiendo de la rama de desarrollo principal, con
el fin de desarrollar sobre ella una determinada característica.
3. La rama de desarrollo incluirá todo el código de la rama principal.
4. Una vez completada esta característica por rama, esta convergirá de nuevo con la
línea principal de desarrollo.
11. Flujos de actividades
Verificar y realizar pruebas de software.
1. Usar una rama distinta a la principal y de desarrollo que contenga código con
cierto grado de garantía.
2. Sobre esta rama no se realizara desarrollo ya que solo servirá para pruebas de
validación de código.
3. Esta rama contendrá el código, correspondiente a características completas para
su validación.
13. Flujos de actividades
Conseguir incrementos de funcionalidades por
entregables de desarrollo.
1. Las ramas por característica también ayudarán a evitar que la línea principal de
desarrollo pueda contener en algún momento del tiempo características
incompletas.
2. Establecer una política de integrar en la rama de desarrollo principal
características completas, provenientes de las rama de características
3. Lograr que la línea principal de desarrollo nunca contenga características a medio
desarrollar.
15. Flujos de actividades
Corrección de errores con el mínimo impacto.
1. Rama por cada versión soportada en la que podamos hacer correcciones de
emergencia para una determinada release.
2. Existirá tantas ramas release como versiones a las que tengamos que dar
mantenimiento.
3. Para corregir errores se debe buscar la línea de código más antigua en la que el
error se reproduce.
4. Salvo parches de urgencia o cuando la complejidad del proceso lo desaconseje,
debemos corregir el bug sobre la línea principal de desarrollo o sobre la línea de
característica.
16. Herramientas
❏ AccuRev
❏ Perforce
❏ ClearCase
❏ Plastic SCM
❏ SpectrumSCM
❏ Surround SCM
❏ Subversion
❏ Git
❏ Microsoft Team Foundation Server
17. Bibliografia
❏ Fairley R. Ingeniería de Software.
❏ Pressman, R.S. Ingeniería del Software. Un
enfoque práctico.