Entrega ContinuaJose Luis Soria, Plain Concepts

ALM Sessions ’12#almsessions12

Jose Luis Soria

ALM Team Leaden Plain Concepts

PST de Scrum.org

jlsoria@plainconcepts.comhttp://geeks.ms/blogs/jlsoria@jlsoriat

Text/Pic

Fuente: State of Agile Development Survey 2011 http://bit.ly/AsvWvK

¿Funciona?

Más ejemplos: Facebook, Amazon, Netflix, Etsy…

¡Liberar frecuentemente,puede incrementarla estabilidad!

¿Te sientes identificado?

Tengo cambios que funcionan perfectamente en un sistema pero fallan en otro.

Una vez que se termina de desarrollar una funcionalidad, se tardan dos semanas en poder tenerla lista en un entorno de producción o similar.

Los programadores y los testers juegan al ping-pong.

Aunque tengo las herramientas adecuadas, sigue siendo difícil obtener feedback.

El proceso de desplegar en producción es muy complejo y nunca se hace de la misma forma.

¿Te suena?

Aunque automatice parte del despliegue, la gente de operaciones se niega a usar las automatizaciones.

No está claro cómo volver a una versión estable si un despliegue va mal.

Cuando hay que liberar una versión, me puedo despedir del fin de semana.

No es posible preparar una demo rápida para un cliente de algo que tengo en desarrollo.

¿Te ha pasado alguna vez?

Me es imposible entregar un pequeño cambio o una corrección de un pequeño error, en un corto espacio de tiempo.

Se ha caído todo el sistema y sólo había tocado una tontería.

Se ha caído todo el sistema y no tengo ni idea de qué se había tocado.

Se ha caído todo el sistema, ¡y no habíamos tocado nada!

Continuous Delivery

El software está listo para serliberado en producción, encualquier punto del ciclo deVidaNo sólo está listo para ser liberado, sino que ademásse libera frecuentemente.Para liberar una versión en producción, bastacon pulsar un botón.

Text/Icon/Pic

¿Por qué entregar frecuentemente?

Feedback rápidoNo se puede asegurar la entrega de valor hasta queno se ha liberado.El feedback es la base que soporta la innovación.

¿Por qué entregar frecuentemente?

Se reduce el riesgo de cadaentregaEl tamaño de lo que se entrega es más pequeño – sihay problemas, se manejan más fácilmente.Casi desaparece el tiempo de investigar losproblemas.Con menos cambios, la vuelta atrás es más sencilla.Se consigue tener mucha más práctica con el procesode despliegue.

tiempo.(Del lat. tempus).1. m. Duración de las cosas sujetas a mudanza.2. m. Magnitud física que permite ordenar la secuencia de los sucesos, estableciendo un pasado, un presente y un futuro. Su unidad en el Sistema Internacional es el segundo

http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=tiempo

tiempo.(Del lat. tempus).1. m. Magnitud imposible de predecir, que transcurre entre que termino de desarrollar una funcionalidad y ésta es liberada en producción.

¿Por qué entregar frecuentemente?

Se conoce el progreso real delproyectoLas estimaciones se deben basar en datos fiables.Cuanto más se separan las entregas, más riesgo hay deque vayan mal.El tiempo entre codificado y liberado es incierto.Done vs. Done Done.Frecuentemente se acumula trabajo sin terminar.Minimizar el lead time.

Las entregas van a ir guiadas por las necesidades de negocio, no por las restricciones operacionales.

Cómo llevarlo a cabo:

Principios de la entregade software

Deployment Pipeline

Cualquier build es “release candidate”

Crea un proceso repetible y confiable para liberar software

Liberar software debería ser fácil, porque todo el proceso habrá sido verificado cientos de veces.

Pasos de un despliegue:Preparar entornosInstalar la versión correspondiente de la

aplicaciónConfigurar el despliegue

¡Todo esto (excepto quizá el hardware) es automatizable!

Automatiza prácticamente todo

Construcción, despliegue, pruebas de aceptación, actualizaciones de la base de datos, configuraciones de entornos…

Hay cosas que no se pueden automatizar: testeo exploratorio, demos al cliente, auditorías…

Trabajando para la automatización

Pla

nifi

caci

ón

Análisi

s

Dis

eño

Codifi

caci

ón

Pru

ebas

Entr

ega

Revis

ión

Testing

Mantén todo bajo control de versiones

Documentación de requisitos, scripts de pruebas, casos de prueba automatizados, scripts de configuración de red, scripts de despliegue, creación y mantenimiento de bases de datos, ficheros de configuración de la aplicación, configuraciones de herramientas, documentación técnica…

Se debería poder reproducir el entorno de ejecución en una máquina limpia, pulsando un botón.Lo mismo para el entorno de desarrollo.

Si duele, hazlo más frecuentemente, y anticípate al dolor

Encuentra lo que más te cuesta hacer, y hazlo más frecuentemente: testing, despliegue, documentación… lo que sea.

Construye con calidad

Lean: “build quality in”

Los defectos son más baratos de corregir cuanto antes se encuentren.

Las pruebas no son una fase, ni van después del desarrollo.

Todo el equipo es responsable de la calidad.

Hecho significa entregado

Done vs. Done Done.

¿Qué significa “hecho” para ti?

No existe “80% hecho”. La condición de hecho es binaria.

Es un esfuerzo del equipo al completo.

Todo el mundo es responsable del proceso de entrega

No nos pasamos la pelota de unos a otros.

Puede haber barreras organizacionales.

Movimiento DevOps.

Mejora continua

La entrega continua no es algo que se implemente y se deje funcionando.

Requiere atención continuada del equipo completo.

Las retrospectivas ayudan.

Cómo llevarlo a cabo:

Prácticas y herramientas

Gestión de la configuración¿Qué versión particular del software estoy usando?

Etiquetas, Ramas¿Quién hizo un determinado cambio?

Histórico¿Por qué se hizo un cambio?

Comentarios del checkin, asociar a WI¿Cómo gestiono las dependencias?

Mapeo de workspaces, ramas, servidor de NuGet¿Cómo gestiono las distintas configuraciones entre entornos?

Transformaciones de ficheros de configuración, gestión de cambios desde las construcciones automatizadas¿Cómo gestiono los entornos?

Virtualización, Lab Management

Integración continua¿Cómo fomentar que se haga checkin frecuente?

¿Cómo puedo tener una batería de pruebas que se ejecute rápido?

Pruebas sencillas, que se hagan en un servidor, entorno dedicado, tareas atómicas, análisis de impacto¿Cómo escalar mi servidor de integración continua?

Máquinas de build, TFS Service, ¿Cómo puedo asegurarme de que no se pasen por alto construcciones automatizadas rotas, o que no pasen todas las pruebas?

Políticas de checkin¿Cómo puedo asegurarme un mecanismo de vuelta atrás?

Lab

Testing

Testing¿Cómo hago pruebas del cuadrante 1?

¿Cómo hago pruebas del cuadrante 2?

¿Cómo hago pruebas del cuadrante 3?

¿Cómo hago pruebas del cuadrante 4?

Deployment Pipeline¿Qué herramientas tengo para soportar el Commit Stage?

¿Qué herramientas tengo para soportar el Acceptance Testing Stage?

¿Qué herramientas tengo para soportar el Manual Testing Stage?

¿Qué herramientas tengo para soportar el Performance Testing Stage?

¿Qué herramientas tengo para soportar el Release Stage?

Q&A, RecursosEnlacesContinuous delivery: http://continuousdelivery.comWeb Deploy http://bit.ly/cUOpfw

Automatización de despliegueswww.secondnug.comMartes 21 de febrero de 19:30 a 21:30

Cursos Professional ScrumCalendario e información http://bit.ly/xc3rPE

jlsoria@plainconcepts.comhttp://geeks.ms/blogs/jlsoria@jlsoriat

© 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.