Charles Darwin y la Entrega Continua

Warning: array_merge(): Argument #2 is not an array in D:\home\site\wwwroot\wp-content\plugins\simple-social-share\simple-social-share.php on line 144

 

Charles Darwin publicó El Origen de las Especies en 1859. No deja de ser admirable que algunas de las teorías que enunció en esta obra se pueden verificar más de 150 años después, en campos del conocimiento humano tan dispares a la biología como puede ser el desarrollo de software.

Para establecer el contexto de los temas que veremos a continuación, antes de abordar cómo nos afectan los enunciados de Darwin, vamos a hacer un pequeño viaje, en el que visitaremos algunas de las empresas más exitosas de Internet, cuyas webs cuentan con cifras astronómicas de usuarios, millones de páginas servidas al día, e incontables cantidades de transacciones completadas.

 

El viaje del Beagle

Lo peligroso es no evolucionar – Jeff Bezos, CEO & Presidente de Amazon.com

Darwin se embarcó en un viaje de casi cinco años a bordo del buque HMS Beagle, que le permitió estudiar multitud de especies animales y obtener información valiosa para soportar las teorías que posteriormente reflejó en su obra. Para estudiar las especies que nos interesan a nosotros, lo tenemos mucho más fácil, pues nos basta con un par de vistazos a algunos contenidos que podemos encontrar en la red, disponibles públicamente.

Empezamos en Seattle, donde una pequeña librería online fundada en un garaje en los años 90, ha acabado convirtiéndose un bazar global donde se puede comprar desde la mítica camiseta de los tres lobos aullando a la luna llena (si no conocías el producto, te recomiendo que leas las evaluaciones de los clientes), a verdadero uranio.

Amazon sirve a 137 millones de clientes por semana y tiene unos beneficios de 34.000 millones de dólares anuales. Si todos sus usuarios activos se juntasen en un país, éste tendría el doble de habitantes que Canadá. Os podéis imaginar que con semejantes cifras, introducir nuevas funcionalidades en el sitio web debe ser algo que se piensen muy mucho, y no se puedan permitir hacer con demasiada frecuencia por el riesgo de aparición de bugs y errores inesperados, que podrían conllevar pérdidas millonarias.

¿Correcto?

No. Nada más lejos de la realidad. En 2011 Amazon estaba liberando cambios en producción cada 11,6 segundos de media, que podían estar afectando hasta a 30.000 servidores a la vez. No dispongo de datos más actualizados, pero por la evolución del negocio, todo hace pensar que estas cifras no habrán hecho más que volverse aún más sorprendentes.

El mayor riesgo es no asumir ningún riesgo… En un mundo que está cambiando realmente rápido, la única estrategia con garantías de fallar es no asumir riesgos. – Mark Zuckerberg, CEO & Chairman de Facebook

1.300 kilómetros al sur, en Menlo Park (California), lo que empezó como el experimento social de un grupo de universitarios, está dando servicio a más de mil millones de usuarios activos, que suben 250 millones de imágenes al día y consultan un billón de páginas al mes. Las cifras que se manejan son simplemente mareantes. La repercusión es tal que incluso hay padres que ponen a sus hijos el nombre de Facebook, literalmente.

El código fuente de Facebook es compilado en un binario que pesa 1,5 GB y es mantenido por más de 500 desarrolladores. En cada modificación y despliegue, hay mucho en juego. Es de esperar que cualquier cambio se haga tras la verificación exhaustiva de un estricto equipo de QA, y nunca sin la aprobación expresa de un ejército de gerentes armados hasta los dientes con la más inflexible burocracia.

¿O quizás no?

La verdad es que, el que se lo imagine así, está muy equivocado. Se sale a producción un mínimo de una vez al día con cambios menores, y una vez a la semana se despliega una versión mayor. Casi todo el código se modifica directamente sobre la línea principal; no usan ramas para proteger la estabilidad de la misma. Todo el mundo hace pruebas y puede reportar defectos. Todo está automatizado al máximo.

En 100 años, la gente echará la vista atrás y dirá: “Eso fue la Era de Internet”. Y los ordenadores se verán como simples ingredientes de esta Era de Internet. – Reed Hastings, CEO de Netflix

No muy lejos de allí, desde un pueblo de California llamado Los Gatos, opera NetFlix. Se trata del mayor servicio de películas y series de televisión online ofrecidas por streaming a sus suscriptores, que suman más de 25 millones.

Los servicios de NetFlix reciben de forma frecuente ataques que hacen peligrar el correcto funcionamiento de los mismos, e incluso provocan caídas en nodos concretos que hacen necesarias intervenciones para evitar problemas mayores. Hasta aquí no es diferente de cualquier otra gran empresa que proporcione servicios en Internet. Lo particular del caso de NetFlix es que gran parte de estos ataques están provocados… ¡por ellos mismos!

¿Cómo es posible? ¿Han perdido la cabeza? ¿Hay empleados descontentos intentando sabotear la compañía desde dentro?

En realidad no. Los ataques están perfectamente orquestados por la Simian Army, el ejército de pequeños incordios desarrollado por NetFlix para llevar al límite su propia infraestructura y aplicaciones. El Chaos Monkey se ocupa de deshabilitar instancias aleatoriamente para asegurarse de que se puede sobrevivir a este tipo de fallo. El Latency Monkey simula retardos y pérdida de conectividad. El Conformity Monkey cierra instancias que no cumplen un conjunto definido de buenas prácticas, directamente y sin mayores contemplaciones. Y así sucesivamente… incluso hay un Chaos Gorilla, el primo de zumosol del Chaos Monkey, que corta de un plumazo el servicio en toda la zona de disponibilidad de la nube en la que desempeña sus monerías. El resultado es que cuando este tipo de problemas aparecen de forma inesperada, todos sus sistemas y equipos ya están preparado para tratar con ellos, puesto que han podido ensayar los procedimientos y el código se ha protegido para mitigarlos. Si la idea te parece interesante, incluso puedes echar un vistazo a cómo está implementado.

En este negocio, para cuando te has dado cuenta de que tienes problemas, ya es demasiado tarde para salvarte. A no ser que te estés preocupando continuamente, estás acabado. – Bill Gates, Co-fundador de Microsoft

Volvemos a nuestra primera parada, Seattle. Justo al lado, en Redmond, el equipo de Team Foundation Service da servicio a muchos otros equipos de desarrollo a nivel mundial, proporcionando una herramienta completa para dar soporte al ciclo de vida de las aplicaciones: planificación, colaboración, control de versiones, ejecución de pruebas, construcciones automatizadas, etc. Con una base de usuarios a nivel mundial, trabajando en todas las zonas horarias, los requisitos de disponibilidad son críticos; todos los que trabajamos en desarrollo de software sabemos el fastidio que supone quedarse sin acceso al control de versiones o que el servidor de construcciones automatizadas no esté disponible. El enfoque usual en estos casos es centrarse en una base estable de características que permitan dar un servicio adecuado a los usuarios y que cambien poco en el tiempo, de esa forma garantizamos que la disponibilidad del servicio no se ve afectada por defectos derivados de la introducción de características nuevas.

¿Estás de acuerdo con este enfoque?

¡Pues ellos no! La tendencia desde el lanzamiento del producto ha sido la de introducir nuevas funcionalidades de forma continua, con cadencias de aproximadamente tres semanas. Y no estamos hablando de cambios menores o estéticos; en esas actualizaciones han entrado características de tanta entidad como el despliegue automatizado a Azure, la integración con Git, o la personalización de tableros Kanban. Las mínimas caídas de servicio acontecidas hasta la fecha han sido en su mayoría previsibles, y en muchas de ellas el usuario es alertado para que pueda estar listo.

De la misma forma que hizo Darwin a bordo del Beagle, podríamos seguir indefinidamente con nuestro periplo en busca de especies peculiares, de otras muchas organizaciones que usan un modo de trabajo que parece desafiar el sentido común o las reglas establecidas:

  • Flickr realiza varios despliegues al día, y hasta hace poco informaba en su web de la hora del último despliegue, y de cuántos cambios había incluido.
  • En Spotify, donde se mantienen más de 100 sistemas distintos entre clientes, servicios de backend, componentes, etc., cualquiera de los 250 desarrolladores está autorizado a modificar cualquiera de estos sistemas directamente si lo necesita para implementar una característica.
  • Etsy experimenta con características nuevas directamente en producción, una técnica conocida como A/B testing, para identificar aquellos cambios que atraen un mayor interés de los clientes.

¿Qué conclusiones podemos sacar a la vista de toda esta información?

¿Se han vuelto todos completamente locos?

¿O estamos ante un nuevo modelo de trabajo, que rompe con muchas de las ideas que considerábamos válidas hasta ahora en desarrollo de software?

Por ejemplo, puede parecer anti-intuitivo pensar que hacer más despliegues te lleve a tener menos problemas al desplegar. Todos hemos tenido esa salida a producción fatídica un viernes (ya se sabe que si no es en viernes, no es un verdadero despliegue…), que nos ha obligado a estar todo el fin de semana luchando para poner la jod$#@ aplicación en marcha. Y la reacción natural es resistirse a volver a desplegar con todas nuestras fuerzas, demorarlo al máximo, ya que sabemos que nos va a doler otra vez. Al fin y al cabo, al haber muchos más intentos, hay también muchas más posibilidades de fallar ¿no es así?

Pues por lo general no. En realidad, el efecto es que la repetición nos lleva a que los despliegues son más predecibles, más controlados, con menos incertidumbre y con problemas mucho más pequeños y controlables. La filosofía subyacente es que si algo duele, en lugar de evitarlo deberías hacerlo más frecuentemente, y así harás el dolor más llevadero. O dicho de otra forma, es más asumible una sucesión de dolores pequeños que un gran dolor traumático concentrado.

¿Es viable que cualquier simple desarrollador tenga el poder de poner en producción cualquier cambio que él considere listo para entregar? Sí, si dicho cambio es sometido a todo un proceso de verificación que asegura que no se va a romper nada si lo liberamos.

¿Es imprudente eliminar de ese proceso de verificación toda una cadena de burocracia, solicitudes, aprobaciones, reuniones entre departamentos y control exhaustivo del proceso por parte de los roles adecuadamente capacitados?

No es para nada imprudente, si todas o la mayoría de esas verificaciones han sido codificadas y se ejecutan en la forma de pruebas de aceptación, de regresión y de humo automatizadas, de despliegues desatendidos, y con la posibilidad de visualizar fácilmente el estado de todo el proceso. No sólo no es imprudente, sino que va a superar con creces la fiabilidad de un grupo de humanos que hagan el mismo proceso (o lo que es peor, una variación aleatoria del mismo) de forma manual, muchas veces en un estado de aburrimiento absoluto y con la concentración bajo mínimos. No me estoy refiriendo a eliminar por completo los pasos manuales, lo cual es por lo general imposible: al menos habrá una primera ejecución manual de las pruebas de aceptación para que el usuario pueda verificar si el equipo de desarrollo ha entendido bien lo que se pretendía conseguir con el requisito concreto. O quizá pueda haber algún dispositivo especial en nuestro entorno para el que no podamos configurar un despliegue totalmente automatizado. Pero sí podemos abordar el resto de nuestro proceso, y tender a minimizar estos pasos manuales en la medida de lo posible.

La Entrega Continua (Continuous Delivery) es una disciplina, un modo de trabajo, o un conjunto de patrones y prácticas, que tiene en cuenta todos estos factores posibles de optimización y los explota al máximo. Nos vamos a basar en técnicas como la automatización de las pruebas y despliegues, la integración continua, la transparencia y visibilidad a lo largo de todo el proceso, el control exhaustivo de todas las dependencias y parámetros de configuración que afectan a la entrega de nuestro software, la detección y tratamiento temprano de cambios problemáticos, y otras muchas, para habilitar la posibilidad de que cualquier mínimo cambio en nuestro código, que se suba al control de versiones, sea candidato a acabar en producción en el mínimo tiempo posible, y de hecho acabe allí si nada nos hace desecharlo (a ser posible automáticamente) en el transcurso todo este proceso.

No se trata tan sólo de despliegue continuo, como muchos erróneamente asumen, ya que puedes estar desplegando basura y aun así hacerlo de forma automatizada continuamente. Tampoco se trata sólo de pruebas automatizadas continuas. Se trata de esas prácticas pero también de otras muchas más; todas aquellas que necesitemos para poder afirmar con garantías que un cambio está listo para que el usuario lo utilice y pueda sacar provecho de su uso.

Por supuesto, para que esto tenga éxito es necesaria una colaboración estrecha entre todos los involucrados, y un entorno en el que se han eliminado barreras y silos departamentales. Algo muy relacionado con lo que movimientos como DevOps se están ocupando de promulgar.

¿Qué ganamos con todo esto?

Si nos guiamos por las cifras que manejan las empresas que trabajan así, podríamos decir directamente que mucho. Pero para evitar caer en la falacia de “correlación implica causalidad”, habría que concretar más, y enfocarnos en el contexto del proceso de desarrollo de software. Lo que nos encontramos entonces es:

  • Un proceso de entrega transparente y predecible. Para todo cambio siempre pasamos por la misma secuencia de pasos, y éstos están automatizados en la medida de lo posible. No hay sorpresas.
  • Menos defectos en producción. Los defectos aparecen y son abordados en fases más tempranas, incluso de forma automática. El proceso de entrega estandarizado evita que ninguno de estos defectos pueda acabar en producción por un malentendido o por formas distintas de hacer las cosas. Además nos aporta trazabilidad sobre el origen de estos problemas.
  • Flexibilidad para asumir cambios. Los cambios se abordan en trozos más pequeños y manejables, se implementan y se entregan lo antes posible.
  • Información más inmediata y útil acerca de los cambios, incluso en el propio entorno de producción: si están funcionando sin problemas, cómo son acogidos por los usuarios o cómo afectan al negocio.
  • Menos tiempo empleado para desplegar y liberar en producción, ya que tenemos todo automatizado al máximo.
  • Equipos motivados por la confianza depositada en ellos y la sensación continuada de estar contribuyendo con incrementos de valor tangibles.

Todo esto suena muy bien, pero no es para mí

La adopción del tipo de prácticas que propone la Entrega Continua puede ser interesante incluso si no necesitamos o si no queremos salir a producción de forma tan frecuente. Los beneficios enumerados en general serán los mismos, por lo que cualquier equipo con afán de mejorar podría plantearse seguir este modo de trabajo.

Hay casos muy especiales en los que la Entrega Continua podría no ser la mejor opción, o incluso sea contraproducente. Yo la verdad es que me he encontrado bien pocos. La mayoría de las ocasiones suelen ser escenarios en los que el esfuerzo de adoptar todas estas prácticas no va a justificar los resultados obtenidos: sistemas legados, tecnologías obsoletas, falta de herramientas adecuadas para montar el entorno necesario, diseños que no favorecen la automatización o las pruebas, etc.

Pero el verdadero problema, que además desafortunadamente suele aparecer con frecuencia, viene cuando el propio equipo o la organización no adoptan una actitud abierta al cambio y a posibles mejoras. Podríamos decir que en el fondo, de modo inconsciente, no quieren un proceso de entrega transparente, no necesitan menos defectos en producción o no buscan flexibilidad ante cambios. De cara al exterior esto se manifiesta como la decisión de que no quieren invertir en las mejoras necesarias. El ejemplo más común es el típico argumento del tipo “nuestro caso es muy singular”, “nuestro sistema es muy complejo”, “el negocio en el que nos movemos es muy delicado”, “nuestros usuarios son muy especiales”, “mi jefe nunca me dejaría”, “mi mamá no me deja” o “inserta tu excusa preferida aquí”. Es especialmente frecuente el de “no podemos permitirnos invertir en eso”, cuando en realidad, como veremos en un momento, lo que seguramente no te puedes permitir es dejar de invertir.

¿Es tu sistema más complejo que Team Foundation Service?

¿Te mueves en un negocio más complejo que Amazon?

¿Son tus usuarios más exigentes y con demandas más variadas que los de Facebook?

¿Tienes que servir más volumen de información que NetFlix?

Si estás entre la gran mayoría de los que responderían negativamente a todas esas preguntas, es muy probable que simplemente te sientas perezoso ante la perspectiva de la transición al modelo de Entrega Continua. En ese caso, mi recomendación es que tengas cuidado, porque a tu organización puede esperarle el mismo destino que al dodo o al tilacino.

Selección natural

A todo esto, nos habíamos dejado a Darwin a bordo del Beagle, navegando por los siete mares en busca de especies singulares. Al final de su viaje estaba perplejo con la variedad de fauna y fósiles que había encontrado, y comenzó una investigación que le llevó a enunciar la teoría de la selección natural en su obra “El origen de las especies”.

No es la especie más fuerte la que sobrevive, ni la más inteligente. Es la que se adapta mejor al cambio.

En la larga historia de la humanidad (y de los animales, también), aquellos que han aprendido a colaborar y a improvisar son los que han prevalecido de forma más efectiva.

Charles Darwin, naturalista inglés

La selección natural nos dice que los miembros de una población con características mejor adaptadas a su entorno, son los que sobreviven con mayor probabilidad. ¿Qué ocurre con los demás? Pues que tarde o temprano acaban desapareciendo.

Es una ley que se aplica a organismos vivos, y si nos paramos a pensar un poco, ¿qué es una organización sino un gran organismo vivo? Por supuesto que la selección natural se aplica a empresas y organizaciones, como cualquier lista de compañías extintas se encarga de demostrarnos.

En el entorno en constante cambio en el que se mueven la mayoría de los negocios, ya no sirve con tener productos buenos, bonitos y baratos. Hay que tenerlos antes, y hacer que evolucionen rápidamente según las demandas de los usuarios. Ya no basta con mantener métricas como la velocidad del equipo o la tasa de defectos. Las métricas que están marcando la diferencia entre los que triunfan y los que se quedan en el camino son otras:

  • Tiempo de ciclo (cycle time): el tiempo que transcurre desde que empiezo a trabajar en una funcionalidad, hasta que la tengo en producción.
  • Tiempo medio entre fallos (MTTF, mean time to failure): lo que tarda mi sistema de media en tener una caída o un corte de servicio.
  • Tiempo medio de recuperación (MTTR, mean time to recover): lo que tardo de media en poner en marcha mi sistema después de una caída.

La selección natural favorecerá a aquellos que sean capaces de mantener estos tiempos en valores lo más pequeños posibles, y es precisamente una de los aspectos en los que la Entrega Continua puede ayudarnos mejor.

Vale, ¡no quiero extinguirme! ¿Por dónde empiezo?

A lo largo de este artículo nos hemos centrado en ver los beneficios de la Entrega Continua y qué puede ocurrir si la ignoramos. Pero no hemos entrado mucho en ver cómo llevarla a la práctica, y dado el gran número de patrones y prácticas a tener en cuenta puede ser un proceso que diste de ser trivial.

Sin lugar a dudas hay una parte del proceso que es cultural, y en la que tendremos que trabajar dentro de nuestra organización para eliminar barreras y silos y mejorar la colaboración en la medida de lo posible.

Para ir guiándonos en los pasos necesarios hay muchos recursos disponibles en los que encontrar ayuda, pero sin lugar a dudas el mejor y más completo es el excelente libro de Jez Humble y David Farley, Continuous Delivery.

Si tu entorno está basado en tecnologías Microsoft, afortunadamente tenemos disponibles herramientas magníficas que pueden dar soporte a la mayoría de las prácticas que hemos mencionado. Visual Studio y Team Foundation Server, y otras herramientas relacionadas, van a servirnos para implementar toda la “pipeline” de Entrega Continua, desde la automatización de todo tipo de pruebas y despliegues, hasta temas más concretos como el análisis estático de código o la integración continua. Es verdad que dichas herramientas necesitan personalización y ajustes para adaptarlas a la forma de trabajar que estamos proponiendo, pero desde Plain Concepts podemos ayudaros a preparar el entorno que mejor se ajuste a vuestro proyecto; es algo que ya hemos hecho para montones de organizaciones, y parece que aún no se ha extinguido ninguna de ellas.

Para hacerte una idea de cómo puede personalizarse Team Foundation Server para dar soporte a la Entrega Continua, también puedes echar un vistazo a mi presentación sobre este tema en el ALM Summit 3.

Y si te puedes permitir esperar, en pocos meses estará disponible un libro en el que estoy colaborando con el equipo de Microsoft Patterns & Practices, y en el que contaremos con todo lujo de detalles qué se necesita para poner en práctica todas estas ideas de forma efectiva. ¡Más noticias acerca de esto en breve!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *