Integración Continua AltNetHispano Carlos Peix

Presentación del tema: "Integración Continua AltNetHispano Carlos Peix"— Transcripción de la presentación:

1 Integración Continua AltNetHispano Carlos Peix (@carlospeix)
Andres Vettori Jose F. Romaniello Vicenç Garcia

2 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

3 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

4 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)

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

6 Elementos

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

8 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…

9 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…

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

11 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

12 Un ejemplo

13 Otro ejemplo

14 Referencias http://martinfowler.com/bliki/FeatureBranch.html

15 ? Preguntas Carlos Peix (@carlospeix) Andres Vettori (@andresvettori)
Andres Vettori Jose F. Romaniello Vicenç Garcia