Diferencia entre revisiones de «Integracion Continua»

De Dos Ideas.
Saltar a: navegación, buscar
(Página nueva: ===Contexto=== Un proyecto de desarrollo de software con Control De Versiones y Automatizacion De Build posee la necesidad de integrar el código con frecuencia para reducir ...)
 
(Deshecha la edición 4868 de 190.232.67.46 (disc.))
 
(No se muestran 7 ediciones intermedias de 5 usuarios)
Línea 1: Línea 1:
===Contexto===
+
La integración contínua es un concepto que surge a partir de la idea de realización de builds diarios. El modelo ideal de integración contínua permite que la construcción y ejecución de pruebas sea realizada cada vez que el código cambia o es enviado al software de [[Control De Versiones]].
  
Un proyecto de desarrollo de software con [[Control De Versiones]] y [[Automatizacion De Build]] posee la necesidad de integrar el código con frecuencia para reducir los riesgos de problemas en la integración final del proyecto.
+
Existe una gran cantidad de [[Herramientas Para Integracion Continua]] en el mercado.
  
===Problema===
+
==Contexto==
 +
 
 +
Un proyecto de desarrollo de software con [[Control De Versiones]] y [[Automatizacion De Build]] posee a necesidad de integrar el código con frecuencia para reducir los riesgos de problemas en la integración final del proyecto.
 +
 
 +
==Problema==
  
 
Integración de código en el trabajo de todo el equipo despúes de ciclos largos (semanas o meses) se torna una sesión de carga a defectos de integración.
 
Integración de código en el trabajo de todo el equipo despúes de ciclos largos (semanas o meses) se torna una sesión de carga a defectos de integración.
Línea 9: Línea 13:
 
Sin integraciones frecuentes no es posible certificar diariamente la estabilidad del producto.
 
Sin integraciones frecuentes no es posible certificar diariamente la estabilidad del producto.
  
===Fuerzas===
+
==Fuerzas==
  
 
* Los problemas de integración se deben detectar idealmente cuando son insertados en el código que puede generarlos.
 
* Los problemas de integración se deben detectar idealmente cuando son insertados en el código que puede generarlos.
Línea 15: Línea 19:
 
* La compilación de código se puede demorar y tornarse un impidimento para la construcción e integración continua del código.
 
* La compilación de código se puede demorar y tornarse un impidimento para la construcción e integración continua del código.
  
===Solución===
+
==Solución==
  
 
Utilice una herramienta que permita realizar la integración contínua del código (al menos una vez por día).
 
Utilice una herramienta que permita realizar la integración contínua del código (al menos una vez por día).
 
Adopte un proceso que torne los resultados de la herramienta cruciales para avalar el estado del proyecto.
 
Adopte un proceso que torne los resultados de la herramienta cruciales para avalar el estado del proyecto.
  
===Raciocinio===
+
==Raciocinio==
  
 
La integración contínua es un concepto que surge a partir de la idea de realización de builds diarios con pruebas de humo.
 
La integración contínua es un concepto que surge a partir de la idea de realización de builds diarios con pruebas de humo.
Línea 43: Línea 47:
 
* La herramienta envía mensajes (por email, page, MSN, etc) para el equipo informando el resultado del proceso de build durante la integración continua.
 
* La herramienta envía mensajes (por email, page, MSN, etc) para el equipo informando el resultado del proceso de build durante la integración continua.
  
===Contexto Resultante===
+
==Contexto Resultante==
  
 
El proyecto posee una herramienta de integración continua que ejecuta automáticamente los builds al mismo tiempo que ocurren las modificaciones en el código.
 
El proyecto posee una herramienta de integración continua que ejecuta automáticamente los builds al mismo tiempo que ocurren las modificaciones en el código.
Línea 51: Línea 55:
  
  
===Patrones Relacionados===
+
==Patrones Relacionados==
  
 
*  [[Control De Versiones]]
 
*  [[Control De Versiones]]
Línea 60: Línea 64:
 
*  [[Radiadores De Informacion]]
 
*  [[Radiadores De Informacion]]
  
===Ver también===
+
==Ver también==
 
* [[Herramientas Para Integracion Continua]]
 
* [[Herramientas Para Integracion Continua]]
 +
* [http://ivanator.wordpress.com/2009/01/12/montando-un-entorno-integracion-continua-hudson-ant-svn-netbeans/ Tutorial para integrar Hudson, NetBeans, Ant y SVN]
  
===Reconocimientos===
+
==Reconocimientos==
  
 
*  (BERCZUK e APPLETON, 2002)
 
*  (BERCZUK e APPLETON, 2002)
Línea 76: Línea 81:
 
*  (RICHARDSON e GWALTNEY, 2005)
 
*  (RICHARDSON e GWALTNEY, 2005)
 
*  (SCHUH, 2005)
 
*  (SCHUH, 2005)
 +
 +
[[Category: Integración Continua]]

Revisión actual del 11:51 18 mar 2010

La integración contínua es un concepto que surge a partir de la idea de realización de builds diarios. El modelo ideal de integración contínua permite que la construcción y ejecución de pruebas sea realizada cada vez que el código cambia o es enviado al software de Control De Versiones.

Existe una gran cantidad de Herramientas Para Integracion Continua en el mercado.

Contexto

Un proyecto de desarrollo de software con Control De Versiones y Automatizacion De Build posee a necesidad de integrar el código con frecuencia para reducir los riesgos de problemas en la integración final del proyecto.

Problema

Integración de código en el trabajo de todo el equipo despúes de ciclos largos (semanas o meses) se torna una sesión de carga a defectos de integración. Integraciones poco frecuentes pueden generar atrasos en el cronograma y problemas de calidad en el producto. Sin integraciones frecuentes no es posible certificar diariamente la estabilidad del producto.

Fuerzas

  • Los problemas de integración se deben detectar idealmente cuando son insertados en el código que puede generarlos.
  • Los desarrolladores no poseen el hábito de hacer check-in de código con frecuencia.
  • La compilación de código se puede demorar y tornarse un impidimento para la construcción e integración continua del código.

Solución

Utilice una herramienta que permita realizar la integración contínua del código (al menos una vez por día). Adopte un proceso que torne los resultados de la herramienta cruciales para avalar el estado del proyecto.

Raciocinio

La integración contínua es un concepto que surge a partir de la idea de realización de builds diarios con pruebas de humo. El modelo ideal de integración contínua permite que la construcción y ejecución de pruebas de humo sea realizada cada vez que el código cambia o es enviado al software de control de versiones.

El proceso de build diario minimiza los riesgos de integración porque los problemas son identificados continuamente. También reduce el riesgo de baja calidad de código, pues un conjunto de pruebas básico permite que las funcionalidades principales del software sean continuamente avaladas.

Grandes empresas desarrolladores de software como Microsoft, Netscape, IBM, Oracle utilizan este proceso de integración continua diaria en sus principales proyectos.

El proceso de integración continua se hace efectivo cuando el build es generado con éxito. En el caso que el build no sea generado debido a problemas, la prioridad del equipo pasa a la corrección de los defectos. Normalmente el error en un build ocurre cuando este no compila o no pasa las pruebas básicas automatizadas.

El proceso de integración continua funciona de la siguiente manera:

  • Los desarrolladores del equipo hacen modificaciones en el código fuente, compilan y ejecutan las pruebas unitarias automatizadas y hacen el check-in (o commit) del código en la línea activa del desarrollo en la herramienta de control de versiones.
  • La herramienta de integración continua de acuerdo a ciertos períodos de tiempo (se recomienda colocar períodos cortos menores a cuatro horas) verifica si nuevo código se ha colocado en la línea activa del software de control de versiones.
  • Si es así, la herramienta de integración continua extrae todo el código fuente y compila en el servidor isolado que tiene por objetivo generar builds limpios.
  • Si compila, la herramienta de integración continua ejecuta otras tareas que pueden ser definidas por la herramienta de build como: compilar y ejecutar pruebas unitarias, pruebas de aceptación, generar información de las pruebas, de la cobertura y de análisis estático de código.
  • La herramienta de Integración Continua actualiza los datos de la página Web del proyecto con todos los resultados de la ejecución del build y con todos los fuentes alterados y con los datos de que se hizo en cada iteración.
  • La herramienta envía mensajes (por email, page, MSN, etc) para el equipo informando el resultado del proceso de build durante la integración continua.

Contexto Resultante

El proyecto posee una herramienta de integración continua que ejecuta automáticamente los builds al mismo tiempo que ocurren las modificaciones en el código.

El Control De Versiones, la Automatizacion De Build y la Integracion Continua se tornan fundamentales para la ejecución continua y automatizada de Automatizacion De Pruebas Unitarias, Automatizacion De Pruebas De Aceptacion, Automatizacion De Metricas De Producto y la generacion de Radiadores De Informacion.


Patrones Relacionados

Ver también

Reconocimientos

  • (BERCZUK e APPLETON, 2002)
  • (CLARK, 2004)
  • (COCKBURN, 2004a)
  • (CUSUMANO e YOFFIE, 1998)
  • (CUSUMANO e SELBY, 1996)
  • (DUVALL, 2007)
  • (FOGEL, 2005)
  • (FOWLER e FOEMMEL, 2006)
  • (MCCONNELL, 1996b)
  • (RICHARDSON e GWALTNEY, 2005)
  • (SCHUH, 2005)