Cómo ser ágiles en el proceso de despliegue
A principios de este mes de marzo, gracias al esfuerzo y motivación de los compañeros de Voxel, se ha organizado el Software Development Summit, evento online a nivel estatal en el que se ha compartido conocimiento y aprendizajes del mundo del desarrollo de software.
Edu ha querido colaborar con el evento presentándonos su visión sobre la agilidad, centrando el foco en aquellos aspectos técnicos que permitan una inspección y adaptación frecuentes evitando costes o riesgos innecesarios durante el proceso de despliegue.
En concreto, nos habla de realizar pasos pequeños y seguros hacia producción de la forma más continuada posible para obtener feedback rápido. Mientras no tengamos algo en producción no estaremos entregando valor ni tampoco estaremos aprendiendo, por contra acumularemos riesgo y coste.
Pasos Seguros
¿Cómo conseguimos realizar pasos seguros en el proceso de desarrollo de producto? Edu nos introduce el concepto de la seguridad psicológica como esencial para asegurar un buen rendimiento de los equipos y su alineación, teniendo en cuenta la diversidad y la inclusión. No obstante, esa seguridad debe complementarse a nivel tecnológico.
Nos remarca la importancia de añadir la calidad necesaria desde el principio y una buena muestra de ello son las prácticas de XP, que aconseja incorporar tests desde el inicio del proceso. Técnicas como el TDD o el BDD son muy comunes y populares para crear esos tests.
Asimismo, también nos comenta que en un sistema complejo el fallo es inevitable, pero lo más importante es que el usuario final no se dé cuenta, de manera que la optimización del tiempo que tardamos en recuperarnos y el radio de impacto de esos problemas son esenciales. Para ello, nos propone técnicas orientadas a los entornos de producción, como Dark Launching, Canary Releasing o Feature Toggles.
Pasos Pequeños, de producto y también a nivel tecnológico
Una vez sabemos hacer pasos seguros, es el momento de centrarnos en que sean pequeños. Y Edu destaca que esto no es responsabilidad única del Product Owner del equipo. Los desarrolladores no son solo programadores, sino también solucionadores de problemas, de manera que es necesario involucrarse estrechamente en el desarrollo de producto.
Edu apuesta por equipos que tengan un buen conocimiento del problema a tratar y una estrategia definida a alto nivel sin entrar en detalles al inicio. También insiste en que construir código es muy caro, y todavía más caro de mantener, de manera que es muy importante evitar implementar código innecesario.
Para ello nos recomienda el Vertical Slicing. Con este approach nos aseguramos realizar pasos pequeños, poco a poco y con cautela, sin pensar más allá de 2-3 incrementos. De esta manera, se obliga al equipo a poner en producción el código para ir obteniendo feedback continuo y repensar el problema a medida que se avanza. Este proceso de iteración y adaptación propicia una mentalidad de experimentación y de hacer MVPs, además de maximizar el trabajo no realizado, ya que se obtiene antes feedback del usuario y se evita coste hundido con código innecesario.
Esos incrementos deberían ser de entre 1 y 3 días desde el punto de vista de producto y deberían incluir siempre valor y aprendizaje. El método que destaca Edu para Vertical Slicing es el método de la hamburguesa de Gojko Adzic porque es muy visual y sencillo de implementar por el equipo.
No únicamente es esencial hacer pasos pequeños a nivel de producto, sino que tienen que ir acompañados por pasos pequeños a nivel de tecnología, lo cual Edu nombra Technical Slicing.
Para ello, debemos poder separar el deployment de la release. Lo primero es código en producción y lo segundo es código en producción visible para el cliente. En ese sentido, es importante poder subir código a producción sin que el cliente se vea afectado directamente por esos cambios. Este approach, por un lado, nos permitirá subir cambios rápido, poder probar e iterar. Por el otro, nos permitirá obtener feedback continuo del mismo sistema de deploy.
Las principales estrategias para hacer ese Technical Slicing son el Dark Launching, el Branch by abstraction y las Feature Flags.
El proceso para cualquiera de ellas se basa en 2 fases diferenciadas, una primera de aislamiento del cambio y de realización de la implementación en paralelo con la versión anterior. Y luego otra de validación del cambio y la eliminación de la duplicidad existente.
Batches pequeños
Una vez ya sabemos hacer pasos pequeños a nivel de producto y a nivel técnico, debemos pensar en cuántos de esos pasos se pueden sacar al mismo tiempo a producción.
Edu nos explica que la cantidad óptima de esos pasos se basa en dos variables, el coste y el tamaño del batch a desplegar, es decir, cuanto cuesta cada bloque/batch desplegado según los incrementos que incorpora. Si hay demasiados incrementos juntos, ¿cuántos errores se nos pueden escapar? ¿cuántas personas son necesarias para corregirlos?
Al final lo más importante es hacer los bloques lo más pequeños posible, teniendo en cuenta el objetivo de la entrega continua de hacer económico y seguro ese despliegue de lotes pequeños. Si no es efectivo el desplegar cada día será porque el proceso nos cuesta mucho o porque no estamos haciendo un buen slicing.
En resumen, para Edu el secreto de la Agilidad está en:
- Pasos seguros.
- Pasos pequeños mediante slicing sin misericordia (Vertical y Técnico).
- Deployar tan frecuentemente como sea posible (Bloques pequeños).
Por la experiencia trabajando con equipos de desarrollo no puedo estar más de acuerdo con Edu, es vital reducir al máximo los incrementos para poder deployar cuánto antes posible y así reducir la incertidumbre gracias al feedback continuo y el coste del retrabajo que puede significar el no construir lo que esperaba el usuario final.
Vuelve a ver la charla:
Sobre el autor:
