Configuración de software

402 views

Published on

Plan de Configuración de Software

Published in: Software
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
402
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Configuración de software

  1. 1. Configuración de Software Ingeniería de Software @jorgedison
  2. 2. Agenda 1. Objetivos 2. Control de versiones 3. Definiciones 4. Flujo de actividades 5. Herramientas 6. Bibliografía
  3. 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. 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. 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. 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. 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.
  8. 8. Flujos de actividades Trabajo concurrente y en equipo del equipo de desarrollo.
  9. 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.
  10. 10. Flujos de actividades Verificar y realizar pruebas de software.
  11. 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.
  12. 12. Flujos de actividades Conseguir incrementos de funcionalidades por entregables de desarrollo.
  13. 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.
  14. 14. Flujos de actividades Corrección de errores con el mínimo impacto.
  15. 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. 16. Herramientas ❏ AccuRev ❏ Perforce ❏ ClearCase ❏ Plastic SCM ❏ SpectrumSCM ❏ Surround SCM ❏ Subversion ❏ Git ❏ Microsoft Team Foundation Server
  17. 17. Bibliografia ❏ Fairley R. Ingeniería de Software. ❏ Pressman, R.S. Ingeniería del Software. Un enfoque práctico.

×