El Gran Elefante DevOps
Durante años la industria software ha reconocido el movimiento Agile como una promesa basada en un conjunto de valores y principios para hacer software de manera sostenible y que nos orientan a la entrega continua de valor. Sin embargo, el mayor foco del movimiento tuvo lugar entre los desarrolladores que, de manera incremental, se adaptaban más frecuentemente a los cambios que venían de negocio involucrando a éste en el propio desarrollo. DevOps extiende estos valores y principios para romper silos con otros equipos/departamentos de TI que aún frenaban la agilidad y adaptabilidad que exige el mercado. Con esos otros equipos nos referimos a Operaciones, Sistemas, Calidad, Seguridad, etc. Se trata pues de crear un flujo de entrega continua de valor y un flujo continuo de feedback que permitan adaptar los productos a las necesidades y demandas de negocio tomando decisiones informadas, involucrando para ello a todas las personas, procesos y herramientas necesarias para gestionar todo el ciclo de vida de los producto o servicios software.
Es por esta amplitud que DevOps se suele comparar como un gran elefante, para el que, según la perspectiva del observador, solo ve una parte de él: la Cultura de colaboración, la Automatización requerida para confiar en un flujo continuo de entrega, las Medidas para asegurar el feedback continuo, y el Sharing o transparencia del conocimiento e información entre todos los equipos. CAMS es el framework definido por Damon Edwards y John Willis, autores del famoso Podcast DevOps Cafe, para intentar entender correctamente DevOps.
En este post me gustaría ahondar un poco más en una práctica en particular: entrega continua (CD, continuous delivery). Mediante entregas frecuentes se reduce el volumen de riesgo porque en cada una de ellas validamos el producto técnicamente y desde el punto de vista de negocio. Las primeras entregas podrían corresponder a las features o incrementos que más valor aportan, o aquellos que reducen más riesgo, o aquellos que validan una hipótesis de negocio. De esta forma el riesgo que gestionamos es mucho menor y está más repartido, “los equipos ya no sufren ese estrés que suponían las dos entregas que teníamos planificadas al año”. En cada uno de los despliegues a producción tenemos feedback así que podemos adaptar el producto.
Pero ¿todas las compañías de desarrollo software pueden hacer CD? Lo primero es conocer el producto y el contexto y adecuar el nivel de CD a ese contexto. Para ello resulta útil la siguiente clasificación realizada por Jocelyin Goldfein en 2016 según la cual el modelo de negocio y el modelo de despliegue determinan en cierta medida el tamaño de los ciclos y, por tanto, la frecuencia de los ciclos de entrega. Si nuestro contexto viene determinado por infraestructura on-premise es probable que la velocidad de despliegue se vea frenada respecto a infraestructura gestionada en la nube (ya sea sobre PaaS, contenedores, o serverless). Aunque sin duda, dentro del contexto, siempre hay cabida para mejorar y acortar esos ciclos de entrega.
Un aspecto importante es la integración continua, es decir la construcción (codificación, compilación y empaquetado) y el testing (de calidad y de seguridad), que habitualmente se considera sobre artefactos de componentes de aplicaciones pero que aplicaría igualmente a artefactos de componentes de infraestructura y de plataforma.
Otro aspecto importante es la diferencia una entrega de funcionalidad a los clientes o usuarios finales (release) y un despliegue a producción. Tradicionalmente estos términos no se diferenciaban porque se desplegaba en producción dos veces al año coincidiendo con las entregas a cliente. Ahora se trata de realizar despliegues frecuentes en entornos de producción, es decir, desplegar incrementos de forma confiable y rápida. El lead time (tiempo desde que se realiza un commit hasta que llega a producción) no debería ser más de 1 hora, idealmente menos de 30 minutos o el tiempo necesario para que una persona permanezca “enganchada” en la tarea de despliegue y no empiece otra tarea (lo que llevaría a situaciones de intentar desplegar más de un incremento a la vez). Para tener un despliegue confiable, debemos confiar tanto en nuestro código (excelencia técnica, clean code, testing automático) como en el proceso (automatizado, basado en la obtención de métricas e histórico de ejecución de pipelines y mejora continua). Debemos tener un despliegue sin pérdida del servicio, es decir, independizar fallos de despliegue respecto fallos de entrega. Existen multitud de técnicas para este fin, entre las más comunes feature toggle, A/B testing, Blue/Green, Canary Testing, etc. Pero en caso de fallo, es importante implementar mecanismos para la recuperación temprana de fallo, lo cual es más factible de per se, ya que, al desplegar pequeños incrementos, los errores son más pequeños o afectan a una parte menor del sistema, y son más fáciles de solucionar. En cualquier caso, el feedback desde producción es indispensable tanto desde el punto de vista técnico como de instrumentación de negocio.
Jessica Díaz Fernández
Team Leader ITSM4DevOps del Comité de Estándares de itSMF España