Upload
agapito-quijano
View
12
Download
0
Embed Size (px)
Citation preview
Entrega ContinuaJose Luis Soria, Plain Concepts
ALM Sessions ’12#almsessions12
Jose Luis Soria
ALM Team Leaden Plain Concepts
PST de Scrum.org
[email protected]://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
[email protected]://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.