Continuous DeliveryBernadette Martínez Hernández

Una mirada al desarrollo por entregas continuas

Sumario

Ingeniería de Software

Peguntas

Lean

Kanban

Agile

Scrum

Continuous Delivery✓

✓

✓

✓

✓

✓

✓

1

2

3

4

5

6

7

Ingeniería de SoftwareDesarrollo en cascada

Ingeniería de SoftwareDesarrollo en cascada

Ingeniería de SoftwareDesarrollo en cascada

Cuatro valores básicos (manifiesto Agile):

1. Los individuos y sus interacciones por encima de los procesos y las herramientas (COMUNICACION)

2. Entregar software que funciona por encima de hacer la documentación

3. Colaboración con el cliente por encima de la negociación de los contratos

4. Responder al cambio por encima de seguir un plan

El desarrollo ágil no es una metodología. Es un término incluyente que describe varias metodologías

ágiles.

Agile, Lean, Scrum y KanbanAgile

Los doce principios Ágiles son:

1. Nuestra mayor prioridad es satisfacer al cliente a través de la entrega temprana y continua de software con valor.

2. Aceptamos requisitos cambiantes, incluso en etapas avanzadas. Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

3. Entregamos software frecuentemente, con una periodicidad desde un par de semanas a un par de meses, con preferencia por los periodos más cortos posibles.

4. Los responsables de negocio y los desarrolladores deben trabajar juntos diariamente a lo largo del proyecto.

5. Construimos proyectos con profesionales motivados. Dándoles el entorno y soporte que necesitan, y confiando en ellos para que realicen el trabajo.

6. El método más eficiente y efectivo de comunicar la información a un equipo de desarrollo y entre los miembros del mismo es la conversación cara a cara.

Agile, Lean, Scrum y KanbanAgile

Los doce principios Ágiles son:

7. Software que funciona es la principal medida de progreso.

8. Los procesos ágiles promueven el desarrollo sostenible. Patrocinadores, desarrolladores y usuarios deben ser capaces de mantener un ritmo constante de forma indefinida.

9. La atención continua a la excelencia técnica y los buenos diseños mejoran la agilidad.

10.Simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.

11. Las mejores arquitecturas, requisitos y diseños surgen de equipos que se auto-organizan.

12.A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo, entonces mejora y ajusta su comportamiento de acuerdo a sus conclusiones.

Agile, Lean, Scrum y KanbanAgile

PIENSA EN GRANDE, ACTÚA EN PEQUEÑO, EQUIVÓCATE RÁPIDO; APRENDE CON RAPIDEZ

Los principios de desarrollo de software Lean (magro):• Eliminar el desperdicio• Ampliar el aprendizaje• Manejar la incertidumbre tomando decisiones hasta el último momento.(Sin

evadir la planeación, sólo enfocarse en la adaptabilidad)• Reaccionar tan rápido como sea posible• Dar poder al equipo (Las personas no son recursos)• Fomentar la integridad (Refactorización y automatización de pruebas)• Tener una visión clara del ‘todo’• Puntos buenos: Enfoque en el ‘todo’, autonomía del equipo (decide y ejecuta

los procesos que necesita)• Puntos malos: Ignora la necesidad de dividir para analizar en proyectos

grandes, posponer las decisiones puede causar problemas.

Agile, Lean, Scrum y KanbanLean

• Scrum es un marco de trabajo para el desarrollo de software (herramienta que aplica el principio de divide y vencerás)

• Roles, sprint, el equipo crea un incremento de software potencialmente entregable, backlog, reuniones planeadas.

• Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada.

• Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes.

Agile, Lean, Scrum y KanbanScrum

• Puntos buenos: Metas pequeñas y fáciles de cuantificar, una reunión mínima diaria, impulsa la formación de equipos.

• Puntos malos: Inflexible (grupos multitareas), demasiadas reuniones de supervisión, no funciona bien en equipos inexpertos y/o no familiarizados con Agile y/o con problemas internos de confianza, requiere un excelente líder, se enfoca demasiado en lo que los usuarios quieren, la productividad y las metas inmediatas, ignora especializaciones (causa de stress), minimiza en exceso la importancia de la documentación, las entregas terminales a usuarios y los bloqueos.

Agile, Lean, Scrum y KanbanScrum

Agile, Lean, Scrum y KanbanScrum

Agile, Lean, Scrum y KanbanScrum

• Kanban es una herramienta visual de control y manejo de proyectos y procesos que ayuda a administrar efectivamente el flujo de trabajo durante una iteración. Kanban es una herramienta, y como cualquier herramienta, su propósito es resolver un problema... Lean es una filosofía.

• Kanban Standups:o ¿Tenemos cuellos de botella (cola con exceso de trabajo)?o ¿Tenemos algo que bloquea la continuidad del proceso?o ¿Estamos manteniendo nuestro límite de trabajos en progreso?o ¿Tenemos las prioridades claras?o ¿Qué se hizo ayer, qué hay que hacer hoy?

• Tablero o pizarrón Kanban se actualiza por lo menos una vez al día. El encargado de cada reunión enumera trabajo, NO gente. Reglas de control de calidad para el movimiento de tarjetas

• Principio de mejora continua. Preguntar ¿POR QUÉ? hasta que duela• Gente con diferentes habilidades tiene que trabajar en equipo para terminar las metas.• No desarrollar features que nadie quiere en este momento. No escribir más especificaciones

de las que se pueda desarrollar. No hacer pruebas en más software del que se planee instalar. Descomposición de ideas en features redituables.

Agile, Lean, Scrum y KanbanKanban

• Puntos buenos: Los mismos de Scrum además de ser más flexible (no hay iteraciones!) y proporcionar una manera de controlar los bloqueos ,la sobrecarga de trabajo y no ignorar la documentación ya que se vuelve parte del proceso. Apunta hacia el desarrollo por entregas continuas.

• Puntos malos: Se enfoca demasiado a satisfacer lo que los clientes quieren, la productividad y las metas inmediatas, ignorando especializaciones (causa de stress) además de la estimación y la planeación, el principio de mejora continua puede cansar o presionar en exceso, requiere mucha disciplina.

Agile, Lean, Scrum y KanbanKanban

Agile, Lean, Scrum y KanbanKanban

No hay herramientas ni filosofías perfectas, entonces lo mejor es combinar y ajustar.

Scrumban con un toque de sal, limón y chile

Agile, Lean, Scrum y Kanban

Continuous Delivery

Desarrollo por entregas continuas

El flujo de trabajo reforzado por Kanban apunta a que un punto ignorado en el que nos debemos enfocar es el perfeccionamiento del movimiento de tareas en el flujo, independientemente de qué tareas se estén procesando. Por ejemplo; al usar Kanban se considera una falla el regresar tareas a colas previas. Cuando la causa de esa falla, está en el proceso, debemos eliminarla.

¿En tu organización, cuánto tiempo pasa para que una línea de código llegue a producción?

¿Cuánta confianza tienes en tu producto?

• Continuous Delivery significa que un producto es considerado terminado desde el día uno del proyecto y puede ser dado a los clientes, incluso si no todas las características y features han sido implementados.

• Da prioridad a la retroalimentación para evitar:– Retrasos en la compilación , documentación y construcción de instaladores– Esperas largas de ejecutables adecuados par a efectuar tests– Reportes de bugs y problemas semanas después de haber concluido un proyecto– Identificación de problemas estructurales justo cuando el proyecto está a punto de concluir

• Jez Humble y David Farley Continuous Delivery (Addison Wesley, 2010)• ThoughtWorks lo usa y provee una herramienta gratuita (Go). Libro se usa

como texto en Oxford en la materia de Prácticas de Ingeniería Ágil.

Continuous DeliveryDesarrollo por entregas continuas

Continuous Delivery

Define

Desarrolla

Implanta

Continuous DeliveryPoner en acción las mejores prácticas en tres áreas principales dentro de una organización

Procesos Personas Herramientas

• Implantación (deployment) repetible y confiable• Repetición de procesos difíciles hasta que sean entendidos, simplificados

y/o automatizados• Automatizar TODO• Versionar TODO (junto con la compilación y corrida automática de tests

compone Continuous Integration)• Terminado = Considerado en ambiente de producción (aunque no

siempre se haga público para que pueda ser instalado como sucede en el paradigma de Continuous Deployment)

• TODOS son responsables de proceso de emisión del software (release)• Calidad desde la primera emisión del software.• Mejora continua.

Continuous DeliveryPrincipios

• Compilar el producto una sola vez• Usar el mismo mecanismo de implantación para todos los

ambientes• Correr test preliminares (no exhaustivos) • Cualquier falla hace que la línea de producción se detenga.• Desarrollo en la Tubería de Montaje

– Equipo de desarrollo y entrega → Control de versiones → Tests de compilación y unit tests → Tests de aceptación automatizados → Tests de aceptación del usuario → Release

– Esto no es nuevo, es simple y llano método científico (Planteamiento del problema, formulación de la hipótesis, experimentación, ley)

Continuous DeliveryPrácticas

• Cada que se salva código en el sistema de control de versiones se activa una corrida de la tubería y el software se compila, se corren los tests y si todos ellos son satisfechos el software puede publicarse.

• Ventajas:– Método probado que permite crear, verificar y montar sistemas complejos de gran

calidad a un costo y riesgo menor. Confianza en el producto (test, test, test) – Evitar el “en mi maquina funciona” vía tests en entornos parecidos a los de

producción (VM, Plataform As A Service [cloud])o Test de aceptación automáticoso Test de aceptación de los usuarioso Test de capacidad

– Recibir noticia inmediata de errores y regresiones además de proveer una aplicación terminada tan pronto y tan frecuentemente como sea posible

– Incrementa la visibilidad del nivel de terminación del producto ya que hay retroalimentación temprana cada vez que hay una nueva versión.

– Facilita el montaje de versiones especificas

Continuous DeliveryLa Tubería de Montaje (Deployment Pipeline)

• Paralelización insuficiente• Mal diseño de la tubería de tal suerte que ciertos tests

no se pueden saltar o reordenar, no se le puede dar prioridad a ciertas versiones o el proceso es muy lento

• Falta de herramientas que permitan alternar entre ambientes “en vivo” y “en proceso de testing” (staging)

Continuous DeliveryProblemas que pueden ocurrir

• Adecuado para Kanban• Principios clave para la Tubería:

– Construir ejecutables una sola vez, almacenarlos en el repositorio de productos y mandarlos a la Tubería – Promover únicamente las versiones que pasen todos los unit tests y los tests de aceptación– Los ambientes de desarrollo, corrida de tests (automatizados y de aceptación) y staging deben ser lo más

similares posible al ambiente de producción.

• Automatizar TODO: compilación, configuración y tests. Los seres humanos tienden a cometer errores en procesos repetitivos.

• Versionar TODO, incluida la configuración del sistema operativo, infraestructura y equipo de red. Para el versionado de la Base de Datos

– Versionar la base de datos y usar una herramienta para manejar los cambios– Compatibilidad hacia adelante y hacia atrás con respecto a la base de datos– Cambios aditivos solamente– Tests adecuados que creen solo los datos necesarios– Evitar integraciones entre aplicaciones vía base de datos

• Continuous Integration (SVN, GIT)• Continuous Deployment (Cloud Foundry)• Switch para features• Staging

Continuous DeliveryConceptos importantes

• Capítulo 5 sobre la Tubería: http://ptgmedia.pearsoncmg.com/images/9780321601919/samplepages/0321601912.pdf

• http://www.infoq.com/presentations/Continuous-Delivery• http://www.infoq.com/interviews/jez-humble-agile2011• http://www.infoq.com/articles/humble-farley-continuous-delivery• http://continuousdelivery.com/• http://continuous-delivery.thoughtworks.com/• http://www.slideshare.net/jmcgarr/continuous-delivery-8341276• http://www.davefarley.net/

Continuous DeliveryMás información

Done and ready for deployment.

ProductionDevelopment

Test Planning

QA

Development Cycle

DevelopmentDevelopment cycle: TDD

Write a test or a set of tests according to the specification and check they fail.

Fix code so all previous tests pass or improve the quality of the code or its efficiency.

Code passes all the tests.

Some tests fail or some code can be improved.

Why:1. If a task goes back into the cycle

is because the requirements changed, not because somebody understood them wrong, didn’t have them at all, or unexpected things got broken.

2. TDD + Scrumban enforces discipline and quality.

3. Eventually, iteration and retrospectives blend in, creating an atmosphere of continuous production.

DevelopmentProduction

Scrumban

TDD

Ideas, breakdown features, tasks ready for development

Prioritized backlog, test planning, development cycle, QA, done, extra, urgent

Waiting for installer, test installer, needs documentation

Altienban

Definition

Deployment

Development

All items To Do

Waste

AltienbanKanban

• If there is nothing to take on my usual queue and I cannot start or continue more work in other queues without passing the WIP limit of any queue maybe it is time for a standup. Board may be inaccurate or I can do something to unblock a currently blocked item but I may not know about it. The following guidelines can be useful to help in this situation:

– Can you help progress an existing Kanban? Work on that.– Don’t have the right skills? Find the bottleneck and work to release it.– Don’t have the right skills? Pull in work from the queue.– Can’t start anything in the queue? Is there any lower priority to start investigating?– There is nothing lower priority? Find other interesting work.

• Stop the Line for special cause problems. Retrospectives with Operations Reviews for common cause problems and reassess the whole value stream

• If requirements are not complete at the definition state, it is OK, we only need to get as much info as possible at that point. Be creative to do that (e.g. drawings and simulations). Requirements may change later, but at least we avoid waste on things that could have initially avoided.

• Development cycle requires developer to run the feature test and all the relevant tests. QA does the wrap-up of the tests and checks nothing is missing before declaring it done. M may do the more complex or manual tests. Possibly check their interaction with other finished work.

• Minimal requirement is that the code is decent enough for someone to take over. If not perfect at least documented or with references of who to ask.

• Test planning: write or get a problem or task specification. Write a test, check if the test fails. Write tests easy to maintain. Initial tests should not break the encapsulation!

• Documentation should be easy to draw from cases if all examples and explanations are there.

AltienbanDetails

• Mejora de la integración continua por medio de una serie de reglas y monitoreo además del uso de GIT como método suplementario de integración continua.

• Manufactura de la documentación ha mejorado considerablemente gracias a que los casos son especificados de mejor manera.

• Parte de los tests están automatizados (número de unit tests se ha incrementado) y cada que se salva código en el sistema de control de versiones, se corren test básicos (continuous integration)

• La compilación y construcción de los programas de instalación ha sido automatizada en su mayoría, aunque aún requiere una persona a cargo que supervise y dos o tres pasos manuales.

• Bases de datos están versionadas y con un método bastante seguro y establecido de adición de cambios.

• Reducido el tiempo de entrega de producto de tres-seis meses a un mes si es necesario, teniendo varios RCs entre periodo y periodo.

AltienbanEn este momento….

• Cambio de actitud– Garantizar tiempo para efectuar las mejoras– Continuidad– Disciplina y participación de todas las esferas de la organización– Importancia de la implementación y ejecución de tests

• Lidiar con los contras de CD– Dificultad de implementar al 100% en una sola iteración, lento proceso de mejoras continuas que

puede exasperar – Implementación de la tubería completa demanda muchísima dedicación y tiempo que es difícil de

conseguir en una compañía de tamaño pequeño.• Planes futuros:

– Automatización completa de la compilación, construcción de programas de instalación e implantación

– Reducción del ciclo de producción y mejora del diseño de la Tubería de Montaje (permitir staging)– Implantación automática en maquinas virtuales que ejecuten series de tests automáticamente– Mejora de tests: más DSLs, mejor TDD y usar Selenium además de VM para la instalación y

corrida automática de tests.– Herramienta de manejo y tests automáticos para las bases de datos usadas por el producto.

AltienbanMayores retos

¡Gracias!

¿Preguntas?