Diferencia entre revisiones de «Control De Versiones»
(Página nueva: ===Contexto=== Un proyecto para el desarrollo de software en una organización, percibe la necesidad de organizar sus activos de software como documentos, archivos de código fuente,...) |
|||
| Línea 1: | Línea 1: | ||
| − | + | =Contexto= | |
Un proyecto para el desarrollo de software en una organización, percibe la necesidad de organizar sus activos de software como documentos, archivos de código fuente, archivos de configuración, etc. | Un proyecto para el desarrollo de software en una organización, percibe la necesidad de organizar sus activos de software como documentos, archivos de código fuente, archivos de configuración, etc. | ||
| Línea 5: | Línea 5: | ||
El equipo de desarrollo nota la necesidad de mantener centralizados los artefactos críticos del proyecto y controlar las modificaciones. | El equipo de desarrollo nota la necesidad de mantener centralizados los artefactos críticos del proyecto y controlar las modificaciones. | ||
| − | + | =Problema= | |
La productividad del equipo disminuye, el número de errores aumenta y el retrabajo crece cuando los desarrolladores: | La productividad del equipo disminuye, el número de errores aumenta y el retrabajo crece cuando los desarrolladores: | ||
| Línea 14: | Línea 14: | ||
* No pueden realizar desarrollo en paralelo. | * No pueden realizar desarrollo en paralelo. | ||
| − | + | =Fuerzas= | |
* Un equipo precisa de una solución simple para organizar los artefactos, y al mismo tiempo debe ser funcional y útil. | * Un equipo precisa de una solución simple para organizar los artefactos, y al mismo tiempo debe ser funcional y útil. | ||
| Línea 22: | Línea 22: | ||
* Un repositorio centralizado puede dificultar el desarrollo distribuido. | * Un repositorio centralizado puede dificultar el desarrollo distribuido. | ||
| − | + | =Solución= | |
Utilice una herramienta de control de versiones que soporte las necesidades de control de ítems de configuración, código compartido, y de desarrollo en paralelo, y que al mismo tiempo sea simple y flexible. | Utilice una herramienta de control de versiones que soporte las necesidades de control de ítems de configuración, código compartido, y de desarrollo en paralelo, y que al mismo tiempo sea simple y flexible. | ||
| Línea 31: | Línea 31: | ||
| − | + | =Raciocinio= | |
| Línea 38: | Línea 38: | ||
Si es usado correctamente, permite que los desarrolladores consigan recuperar versiones antigüas de software y corregir defectos en versiones en producción sin para el desarrollo de una nueva versión del producto. Todos los archivos necesarios para la generación de un build del producto se encuentran en el repositorio. De esa forma, los desarrolladores pueden trabajar con código compartido y sincronizar frecuentemente el código de su máquina con el código de los otros desarrolladores a través del repositorio. | Si es usado correctamente, permite que los desarrolladores consigan recuperar versiones antigüas de software y corregir defectos en versiones en producción sin para el desarrollo de una nueva versión del producto. Todos los archivos necesarios para la generación de un build del producto se encuentran en el repositorio. De esa forma, los desarrolladores pueden trabajar con código compartido y sincronizar frecuentemente el código de su máquina con el código de los otros desarrolladores a través del repositorio. | ||
| − | + | =Contexto Resultante= | |
El proyecto posee un software de control de versiones y una estructura de directorios que favorecen la estabilidad y seguridad del desarrollo en equipos, con la aplicación de este patrón. | El proyecto posee un software de control de versiones y una estructura de directorios que favorecen la estabilidad y seguridad del desarrollo en equipos, con la aplicación de este patrón. | ||
| Línea 52: | Línea 52: | ||
Algunos de esos integrantes no necesariamente poseen la necesidad de instalación del cliente de la herramienta del control de versiones, el uso de [[Radiadores De Informacion]] torna siempre visibles las últimas actualizaciones de los artefactos. | Algunos de esos integrantes no necesariamente poseen la necesidad de instalación del cliente de la herramienta del control de versiones, el uso de [[Radiadores De Informacion]] torna siempre visibles las últimas actualizaciones de los artefactos. | ||
| − | + | =Patrones Relacionados= | |
* [[Automatizacion De Build]] | * [[Automatizacion De Build]] | ||
| Línea 60: | Línea 60: | ||
* [[Radiadores De Informacion]] | * [[Radiadores De Informacion]] | ||
| − | + | =Herramientas= | |
[[Herramientas Para Control De Versiones]] | [[Herramientas Para Control De Versiones]] | ||
| − | == | + | =Reconocimientos= |
* (BERCZUK e APPLETON, 2002) | * (BERCZUK e APPLETON, 2002) | ||
| Línea 75: | Línea 75: | ||
* (PALMER e FELSING, 2002) | * (PALMER e FELSING, 2002) | ||
| − | + | =Ver También= | |
* Named Stable Bases (COPLIEN e HARRISON, 2004) | * Named Stable Bases (COPLIEN e HARRISON, 2004) | ||
* Private Versioning (COPLIEN e HARRISON, 2004) | * Private Versioning (COPLIEN e HARRISON, 2004) | ||
* Repository (BERCZUK e APPLETON, 2002) | * Repository (BERCZUK e APPLETON, 2002) | ||
Revisión del 15:16 25 jul 2008
Contenido
Contexto
Un proyecto para el desarrollo de software en una organización, percibe la necesidad de organizar sus activos de software como documentos, archivos de código fuente, archivos de configuración, etc.
El equipo de desarrollo nota la necesidad de mantener centralizados los artefactos críticos del proyecto y controlar las modificaciones.
Problema
La productividad del equipo disminuye, el número de errores aumenta y el retrabajo crece cuando los desarrolladores:
- No comparten código entre sí de una forma controlada.
- No controlan todas las modificaciones realizadas y no saben los motivos de cada una de ellas.
- No pueden recuperar versiones antiguas de ítems de configuración de software.
- No pueden realizar desarrollo en paralelo.
Fuerzas
- Un equipo precisa de una solución simple para organizar los artefactos, y al mismo tiempo debe ser funcional y útil.
- La estructura de directorios del proyecto no está definida o ésta es complicada o inflexible.
- Los desarrolladores necesitan trabajar con una versión correcta del software, sin generar problemas para los desarrolladores que están trabajando con versiones diferentes del software.
- Con el desarrollo iterativo es interesante registrar el estado de la versión de cada iteración.
- Un repositorio centralizado puede dificultar el desarrollo distribuido.
Solución
Utilice una herramienta de control de versiones que soporte las necesidades de control de ítems de configuración, código compartido, y de desarrollo en paralelo, y que al mismo tiempo sea simple y flexible.
Piense en una estructura de directorio inicial que se pueda actualizar con el correr del proyecto.
Utilice una herramienta de control de versiones que permita la creación de repositorios distribuidos, cuando no sea posible el uso de un repositorio centralizado.
Raciocinio
Una herramienta de control de versiones es uno de los ítems fundamentales para establecer un software de gestión de configuración eficaz (BERCZUK e APPLETON, 2002) e (BECK, 2004). Los procesos ágiles se refieren al software de control de versiones como su herramienta mas crítica, atrás apenas del compilador. Solamente con esta herramienta es posible registrar todas las modificaciones ocurridas en el código fuente durante el proyecto.
Si es usado correctamente, permite que los desarrolladores consigan recuperar versiones antigüas de software y corregir defectos en versiones en producción sin para el desarrollo de una nueva versión del producto. Todos los archivos necesarios para la generación de un build del producto se encuentran en el repositorio. De esa forma, los desarrolladores pueden trabajar con código compartido y sincronizar frecuentemente el código de su máquina con el código de los otros desarrolladores a través del repositorio.
Contexto Resultante
El proyecto posee un software de control de versiones y una estructura de directorios que favorecen la estabilidad y seguridad del desarrollo en equipos, con la aplicación de este patrón. Los artefactos principales del software se encuentran dentro del repositorio definido para el proyecto.
Con el software de control de versiones y una Automatizacion De Build operacional es importante certificar que toda nueva modificación del código en el repositorio (un check in) no quiebre el build. Eso nos da la posibilidad de realizar integraciones frecuentes a través del patrón Integracion Continua.
Un software de control de versiones no siempre posee la información relevante del motivo de una determinada modificación y con cual incidencia este se relaciona. El uso de Flujo De Incidencias integrado con la herramienta de control de versiones es una herramienta de gestión de incidencias y una forma de solucionar este nuevo problema.
La necesidad de mantener el repositorio visible con facilidad para otros integrantes puede ser importante para el proyecto. Algunos de esos integrantes no necesariamente poseen la necesidad de instalación del cliente de la herramienta del control de versiones, el uso de Radiadores De Informacion torna siempre visibles las últimas actualizaciones de los artefactos.
Patrones Relacionados
- Automatizacion De Build
- Integracion Contínua
- Flujo De Incidencias
- Rastreabilidad
- Radiadores De Informacion
Herramientas
Herramientas Para Control De Versiones
Reconocimientos
- (BERCZUK e APPLETON, 2002)
- (COPLIEN e HARRISON, 2004)
- (RICHARDSON e GWALTNEY, 2005)
- (COCKBURN, 2004a)
- (BECK, 2004)
- (FOGEL, 2005)
- (MASON, 2005)
- (PALMER e FELSING, 2002)
Ver También
- Named Stable Bases (COPLIEN e HARRISON, 2004)
- Private Versioning (COPLIEN e HARRISON, 2004)
- Repository (BERCZUK e APPLETON, 2002)
