Los primeros pasos hasta configurar un ambiente de Integración Continua son siempre complicados, pero una vez creado el ambiente de integración continua ya no imaginamos nuestro trabajo sin él. En esta charla se plantearán los conceptos básicos y teóricos de una de las prácticas más conocidas de Extreme Programming y seguidamente se mostrará un ejemplo práctico paso a paso para la implementación de un ambiente de CI utilizando herramientas como Cruise Control, CC Tray, NUnit y Selenium.
A build may consist of the compilation, testing, inspection, and deployment - among other things. A build acts as the process for putting source code together and verifying that the software works as a cohesive unit. La idea es saber si el software en su conjunto funciona bien, es por eso que tener tests automaticos es fundamental. Hacer una compilacion continua no tiene poco o ningun valor
Describir los componentes tipicos de un ambiente de CI y los pasos que se llevan a cabo: Desarrolladores corren builds privados Commitean codigo al repositorio El Servidor de IC verifica constantemente si hay nuevas versiones del software, y cuando hay dispara una serie de tareas definidas en los scripts de build Tareas: compilacion, integracion de bd, ejecucion de tests, ejecucion de inspecciones, deployment en caso que fuera necesario Los resultados son revisados
- Todos los desarrolladores corren builds privados en sus estacions de trabajo antes de comittear código al repositorio de control de versiones, para asegurar que sus cambios no rompan el build de integracion - Los desarrolladores comitean al repositorio al menos una vez al dia - Builds de integracion ocurren varias veces al dia en una maquina separada de builds - 100% de los tests deben pasar para cada build - Corregir builds rotos - Algunos desarrolladores revisan reportes generados en el build, como estandares de codigo o cobertura de los tests, para buscar areas de mejora.
Continuous Integration increases your opportunities for feedback. Through it, you learn the state of the project several times a day. CI can be used to reduce the time between when a defect is introduced and when it is fixed, thus improving overall software quality. CI increases the collective confidence of teams and lessens the amount of human activity needed on projects, because it's often a hands-off process that runs whenever your software changes. CI involves much more than a tool. Requiere compromiso del equipo en relacion a actividades como commitear frecuentemente al repositorio, arreglar los broken builds inmediatamente o usar una maquina de build separada.
![Adrián Eidelman Kinetica Solutions [email_address] Twitter: @aeidelman Rubén Altman Kinetica Solutions [email_address] Twitter: @raltman](https://image.slidesharecdn.com/giles2009-presentacin-091014075043-phpapp02/85/Agiles-2009-Integracion-Continua-Dando-los-primeros-pasos-a-traves-de-un-ejemplo-practico-1-320.jpg)
![[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Antes de arrancar](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)