Integración Continua AltNetHispano Carlos Peix (@carlospeix) http://carlospeix.com/ Andres Vettori (@andresvettori) http://weblogs.asp.net/andresv Jose F. Romaniello (@jfroma) http://jfromaniello.blogspot.com/ Vicenç Garcia (@vgaltes) http://devnettips.blogspot.com/

Agenda Integración automatizada Elementos Políticas de release Políticas de branching Rigidez: difícil de cambiar Fragilidad: fácil de romper Inmovilidad: difícil de reutilizar Viscosidad: difícil de modificar correctamente En el diseño mismo En el ambiente (compilación, control de fuentes, herramientas que no favorecen una buena manera de hacer las cosas; o la carencia de aquellas que la facilitan). Complejidad: sobre-diseño ó sobre-arquitectura; exceso de especulación Repetición: exceso de “copy/paste development” Opacidad: falta total de expresividad Sample: TheCopyProgram

Integración automatizada ¿Por qué? Reduce riesgos Reduce trabajo repetitivo Evita pérdida de tiempo corriendo pruebas Facilita tener el software “siempre listo” Maximiza la visibilidad sin esfuerzo Genera confianza en el equipo y el cliente

Integración automatizada ¿Cómo? ¿Cuándo? Al principio del proyecto Primero lo mas sencillo, luego agrego Sobre un servidor dedicado (Fuera VS!!!) Todos monitorean (CCTray o similar)

Elementos Source control Build automation Build scheduler (CruiseControl.NET, TeamCity, Hudson, TFS) Políticas de branching Practicas relacionadas

Elementos

Source control Elegir la herramienta correcta Subversion Git o Hg (distribuidos) TFS src-2010-01-03.zip no es source control! Source Safe ya dejémoslo tranquilo! Elegir una política de branching adecuada a la política de release

Build automation Es la parte mas importante! NAnt, MSBuild, Maven, PowerShell? Todas las herramientas se parecen Todas son extensibles Elijan la que mas les guste Ejemplo…

Build scheduler CruiseControl.NET, TFS, TeamCity, Hudson Por lo menos tiene que saber leer el repositorio y disparar el build Casi todos muestran estadísticas muestran el resultado del build bien detallado avisan cuando algo salió mal Ejemplo…

Prácticas relacionadas Commits frecuentes Colective Code Ownership Unit testing Test para los bugs

Políticas de branching Lo tradicional: trunk/tags/branches Dependen de la política de release Software que se distribuye: potencialmente se requiere dar soporte a mas de una versión Software que se ofrece como servicio (SaaS): suele mantenerse una única versión

Un ejemplo

Otro ejemplo

Referencias http://martinfowler.com/bliki/FeatureBranch.html http://www.cmcrossroads.com/bradapp/acme/branching/branch-policy.html http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.cc_proj.doc/c_bntr_plnbrstrat.htm http://martinfowler.com/articles/continuousIntegration.html http://integratebutton.com/

? Preguntas Carlos Peix (@carlospeix) Andres Vettori (@andresvettori) http://carlospeix.com/ Andres Vettori (@andresvettori) http://weblogs.asp.net/andresv Jose F. Romaniello (@jfroma) http://jfromaniello.blogspot.com/ Vicenç Garcia (@vgaltes) http://devnettips.blogspot.com/