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