Transcript la presetnación

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
2
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
3
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)
4
Elementos
 Source control
 Build automation
 Build scheduler (CruiseControl.NET,
TeamCity, Hudson, TFS)
 Políticas de branching
 Practicas relacionadas
5
Elementos
6
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
7
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…
8
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…
9
Prácticas relacionadas







Commits frecuentes
Colective Code Ownership
Commits frecuentes
Unit testing
Commits frecuentes
Test para los bugs
Commits frecuentes
10
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
11
Un ejemplo
12
Otro ejemplo
13
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/
14
Preguntas
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/
15