Integración Continua …¿Por qué? ¿Como?
Ernesto Cárdenas Cangahuala (@fisica3)
Software Engineer, Agilista, fotografoaficionado
Erase una vez… un desarrollador
En la Universidad
!En mi casa compilaba!
Durante el Desarrollo
¿Qué has hecho ayer en todo el día?
…Subir el proyecto a preproducción
…Mantenimiento
¡La web de producción esta grabando en la BD de preproducción!
Este… ayer subí la corrección de un bug….
¡Además ahora las formulas dan valores incorrectos!
Integración Continua
Martin Fowler:“La integración continua es una práctica
de desarrollo de software en la cuál los miembros de un
equipo integran su trabajo frecuentemente, como mínimo
de forma diaria. Cada integración se verifica mediante una
herramienta de construcción automática para detectar los
errores de integración tan pronto como sea posible.”
¿Que perseguimos con la CI?Ser capaces de controlar la “salud” de nuestro proyecto durante todo el ciclo
de desarrollo y mantenimiento
Que el código que hay en nuestro repositorio “Funcione”
Invertir menos tiempo en integración.
Incrementar la visibilidad del proceso, feedback inmediato.
Reducir el riesgo del proyecto, gracias a la visibilidad de avance.
Incrementar la autonomía de los Testers, que prueben siempre lo ultimo
Dedicar menos tiempo a la creación y despliegue de versiones
Incrementar la confianza entre los usuarios de negocio y el equipo de
proyecto.
Practicas de Integración Continua
Mantener un único repositorio de código fuente
Automatizar la construcción del proyecto
Hacer que la construcción del proyecto ejecute sus propios tests
Construir la línea principal en la máquina de integración
Mantener una ejecución rápida de la construcción del proyecto
Probar en una réplica del entorno de producción
Hacer que todo el mundo pueda obtener el último ejecutable de forma fácil
Publicar qué está pasando (alertas!!!)
Automatizar el despliegue
Ok, ¿Cómo logramos eso?
Una visión general
Elementos
Repositorio: Subversion, Mercurial, TeamFoundation Server, Git
Servidor: Hudson/Jenkins, Team Foundation Server, Bamboo, TeamCity
Reglas: ANT, Nant, MSBuild/XAML
Entorno(s) de despliegue: Web, Windows…
Team Foundation Build Considerado parte del núcleo de la plataforma TFS 2012
Muy integrado con otros servicios y características de TFS
Version Control
Work Item Tracking
Testing
Permite análisis de tendencias históricas
Los miembros del equipo pueden ser notificados del estado de la build, para prevenir checkin que no sean correctivos
MSBuild hace el “building”, Windows Workflow hace la orquestación
Extensible: Soporte Java, Maven, Ant vía TFS Build Extensions
Arquitectura de Team Foundation Build
Application
Tier
Build
Controller
Build
Agent
Symbol
Server
Drop
ServerBuild
Team Build Process
Controlado por un archivo XAML Windows Workflow4.0
Tres plantillas de proceso “out-of-the-box”
DefaultTemplate
UpgradeTemplate
LabDefaultTemplate (y….)
Almacenado en TFS
Se pueden crear plantillas de build personalizadas
Definiendo nuestra Build
Parametrizando
Revisión inmediata
Upss… un error
Seguimiento historico
Principios para el desarrollador
Contribuye a menudo
No contribuyas código roto
Soluciona los build rotos inmediatamente
Escribe tests automáticos
Todos los tests deben pasar
Reforzando el factor humano
Establecer políticas de Check-in, shelve y Code Review
Configurar bien las alertas
Detenerse cuando la Build se cae
Si se cae la Build no es el fin del mundo
Antes de hacer check-in, Get latest versión y probar en local
Probar en ambiente de Integración
Validar siempre la actualización del Modelo de BD
Considerar CodeAnalysis, StyleCop y opcionalmente convertir warning en errors
¿Preguntas?
Enlaces útiles
El Bruno
Jersson on the Block!
SedoDream
How to install Web Deploy on Windows Server 2012
Consultor Internet
Top Related