El desarrollo de software en 2020 es un entorno que cambia rápidamente. Cada día está más claro que si nuestras organizaciones quieren sobrevivir a este periodo de incertidumbre política y económica, deben ser capaces de moverse con rapidez y adaptabilidad. Pero, ¿cómo se controla la seguridad en la velocidad? Si su objetivo es pasar de un ciclo de entrega de software que se construyó con un montón de barandillas y despliegues poco frecuentes, a una metodología más moderna que apoye la capacidad de respuesta a través de lanzamientos frecuentes para hacer fluir el valor a sus clientes de la forma más rápida y segura posible, entonces a quién pone a cargo de las decisiones de gestión del cambio importa, y mucho.
Tradicionalmente en muchas organizaciones, estas decisiones se toman de forma centralizada por un gestor de cambios que lleva a cabo reuniones periódicas de la junta asesora de cambios (CAB). El CAB en sí es un conjunto de representantes de varias funciones dentro y fuera de la TI corporativa, encargados de revisar los cambios propuestos y ayudar al gestor de cambios en la evaluación, priorización y programación de los mismos. Por diseño, se trata de un grupo que no está directamente involucrado en el diseño o la implementación del cambio propuesto, por lo que el proceso que llevan a cabo se conoce como una revisión «externa».
Pero, ¿quién debería estar a cargo? Para apoyar de la mejor manera tanto la velocidad y la seguridad COMO el impacto en el negocio, usted quiere que sus equipos de desarrollo y sus clientes conduzcan su toma de decisiones. Desde una perspectiva técnica, sus desarrolladores tienen una mejor idea de lo que hay en una versión, si existen interdependencias y si se ha probado, que cualquier junta asesora de cambios. Desde una perspectiva empresarial, es hora de que nos demos cuenta de que el cliente es el árbitro final de lo que funcionará y lo que no, no un alto directivo y, desde luego, no su consejo asesor de cambios.
Una Junta Asesora de Cambios puede ser más lenta, pero al menos es más segura, ¿no?
La Junta Asesora de Cambios (y gran parte de lo que encontrará en ITIL), pueden parecer formas razonables de reducir el riesgo y añadir rigor, especialmente en entornos complejos y de movimiento lento. Si sólo tienes una oportunidad cada 30 o 90 días para cambiar la producción, mantener las cosas fuera de los lanzamientos con puertas de calidad y aprobaciones de gestión parece una buena manera de gestionar el riesgo. Nadie discutiría que es un proceso más lento (que puede añadir semanas o meses al tiempo que transcurre entre que un desarrollador escribe el código y lo pone en marcha), pero es más seguro, ¿no?
En realidad, no. No lo es.
Un estudio de varios años a través de una amplia variedad de industrias y entornos encontró que tener un CAB o un proceso similar de «aprobación externa» funcionaba peor que no tener ningún proceso de aprobación. Esto es lo que dijo la autora principal, la Dra. Nicole Fosgren, sobre los resultados:
Encontramos que las aprobaciones externas estaban negativamente correlacionadas con el tiempo de espera, la frecuencia de despliegue y el tiempo de restauración, y no tenían ninguna correlación con la tasa de fracaso de los cambios. En resumen, la aprobación por parte de un organismo externo (como un gerente o un CAC) simplemente no sirve para aumentar la estabilidad de los sistemas de producción, medida por el tiempo de restauración del servicio y la tasa de fracaso de los cambios. Sin embargo, ciertamente ralentiza las cosas. De hecho, es peor que no tener ningún proceso de aprobación de cambios.
¿Qué es mejor que no tener ninguna gestión de cambios?
La Dra. Fosgren y su equipo no están sugiriendo que no se tenga ningún proceso de aprobación, pero teniendo en cuenta lo mal que funcionan los CAB en el mundo real, deberíamos replantearnos qué tipo de proceso le mantendrá realmente seguro.
Aquí hay otra cita del estudio de Accelerate:
Nuestra recomendación basada en estos resultados es utilizar un proceso de aprobación de cambios ligero basado en la revisión por pares, como la programación en parejas o la revisión de código dentro del equipo, combinado con un canal de despliegue para detectar y rechazar los malos cambios. Este proceso se puede utilizar para todo tipo de cambios, incluidos los de código, infraestructura y base de datos.
Revisiones de código por pares combinadas con ¿Y ahora qué?»
Cuando leí esa recomendación en marzo de 2018, no tuve problemas para visualizar la primera mitad: las revisiones de código por pares y las demostraciones semanales del equipo ya eran la norma en BlazeMeter. ¿La segunda mitad? ¡No tanto! Éramos una aplicación SaaS nativa en la nube «moderna», pero nunca había oído hablar de «una tubería de despliegue detectar y rechazar los malos cambios.»
Para gestionar el riesgo durante los lanzamientos de entonces, utilizábamos una combinación de despliegues azules/verdes y lanzamientos canarios. La plataforma se encargaba de «empujar», pero no de «detectar» o «rechazar»: eso dependía de nuestros mejores y más brillantes SRE, que comprobaban la salud de docenas de cosas manualmente antes de que nos lanzáramos a por el 100% de los usuarios. Al leer «detectar y rechazar los malos cambios» sólo aparecía la imagen de una caja negra en una pizarra con la etiqueta «la magia ocurre aquí». Recuerdos a los estudios de cine en la universidad, donde aprendí lo que significaba «deus ex machina».
Detectar y rechazar: Los ejemplos están ahí fuera si buscas
En dos años pueden cambiar muchas cosas. Desde que me uní a Split como evangelista de CD, he visto a Lukas Vermeer describir cómo la tubería de despliegue de Booking.com puede detectar y revertir un mal cambio dentro de un solo segundo. He escuchado a Sonali Sheel de Walmart Labs explicar cómo utilizan su plataforma Expo para detener un despliegue a mitad de camino antes de que haga daño a sus métricas clave, algo que llaman Test to Launch.
La plataforma de entrega de características de Split fue creada por personas con visiones similares de la gestión moderna del cambio basada en experiencias vividas en LinkedIn, Salesforce.com y Yahoo. Los fundadores recibieron consejos de personas que habían abordado la complejidad, la velocidad y la escala de sistemas similares en Amazon y Microsoft.
Cuando oí hablar de Split y descubrí los ejemplos que estaban comercializando, aproveché la oportunidad de unirme a ellos. Construir una plataforma de este tipo internamente era algo que sólo unos pocos gigantes tenían el tiempo y los recursos para abordar. Si el mismo tipo de exposición de grano fino y la detección automatizada de impacto estuvieran disponibles como SaaS, entonces la entrega de software impulsada por el impacto podría desbloquearse para todos los equipos, no sólo para las startups unicornio.
Eso es increíble, pero no funcionará aquí
Una cosa curiosa sucedió una y otra vez cuando viajé a conferencias de tecnología, dando charlas sobre los primeros pioneros que habían construido estas plataformas en casa. El público respondía primero con asombro y luego con resignación. «Eso está muy bien, pero no somos Booking.com, LinkedIn o Facebook. No podemos hacer eso en nuestro entorno».
En mis esfuerzos por ser «vendor-neutral» evitando los detalles de la implementación de Split, prácticamente había vuelto a dibujar esa imagen borrosa de una caja negra marcada como «la magia sucede aquí.»
¿Y si no fuera tan difícil?
Si nunca has visto una plataforma que proporcione un control de grano fino de la exposición y un riguroso mecanismo automatizado para detectar y rechazar los malos cambios en tu entorno, no se te puede culpar por pensar que es ciencia ficción.
Resulta que sólo hay cuatro problemas principales para resolver aquí:
- Desacoplar el despliegue de la liberación, por lo que el código puede ser empujado todo el camino a la producción, pero impidió la ejecución hasta que esté listo. Esto facilita la verdadera integración continua, los pequeños tamaños de lote, el desarrollo de características incrementales, y la ramificación por abstracción, que son todos críticos para tirar de la entrega continua donde el flujo es la norma.
- Exponer selectivamente el nuevo código, comenzando con pequeñas audiencias internas y trabajando hacia fuera. Esto facilita las pruebas en producción, el dogfooding, los programas de acceso temprano y la agrupación de los cambios para los clientes reacios al cambio.
- Ingerir los datos de comportamiento del sistema y de los usuarios y alinearlos con los datos de exposición que indican quién entra y quién sale de cada cohorte de usuarios. El objetivo es hacer que el proceso de atribución (alinear «¿Quién obtuvo qué?», con «Entonces sucedió esto») sea automático y continuo.
- Comparar los patrones de las métricas entre los incluidos y excluidos de cada cohorte para identificar (y opcionalmente alertar sobre) las diferencias significativas. Es posible que haya visto este patrón antes en el contexto de las «pruebas A/B», que normalmente rastrean el impacto de los cambios en una métrica de conversión, pero aquí estamos hablando de rastrear ampliamente el impacto de todo el trabajo de ingeniería y tener una vigilancia siempre vigilante de los impactos en todas las métricas valoradas por la organización, tanto si el impacto en esas métricas se espera como si no.
Entrega progresiva: Una base fácilmente establecida
Desacoplar el despliegue de la liberación y exponer selectivamente el nuevo código se está conociendo como entrega progresiva, un término acuñado por el analista de RedMonk James Governor. Múltiples proveedores comerciales de banderas de características proporcionan estas capacidades fuera de la caja y el consenso está emergiendo que las banderas de características se han unido a la lista de herramientas de desarrolladores que tienen más sentido para comprar que construir y mantener en casa.
Las banderas de características son una base esencial para lograr el flujo, pero por sí solas no aceleran la detección del impacto. La mayoría de las implementaciones de banderas de características facilitan el flujo, pero no hacen nada para indicar si todo va bien o si se están logrando resultados significativos.
Atención: los científicos de datos no escalan
Ingerir el comportamiento del sistema y del usuario y alinearlo automáticamente con las cohortes expuestas es raro entre todos los sistemas internos, excepto los más sofisticados. La mayoría de los equipos que intentan esta práctica están haciendo mucho trabajo de ciencia de datos manual y ad-hoc. Como están limitados por los recursos humanos más que por la capacidad informática, se ven obligados a elegir cuándo y dónde prestar atención.
La carga cognitiva no es su amiga cuando se busca el flujo, por lo que el diseño de Split ni siquiera requiere que los equipos elijan qué eventos asociar con cada lanzamiento de la bandera de características; todos los eventos ingeridos, una vez vinculados a las métricas de la organización, se atribuyen continuamente a las cohortes de encendido y apagado de cada lanzamiento, sin ninguna intervención. Split también facilita el trabajo de identificación e ingesta de datos de eventos mediante integraciones con Segment, Sentry, mParticle y Google Analytics.
Semper Fi for Continuous Delivery Pipelines
Comparar patrones de métricas entre los incluidos y los no incluidos en cada cohorte de forma rigurosa para determinar automáticamente las diferencias significativas es aún más raro en la naturaleza que la atribución. Este es exactamente el problema que resuelven los módulos Monitor y Experimentación de Split. Monitor se centra en identificar y alertar sobre los impactos en las métricas a medida que un despliegue está en marcha (también conocido como «limitar el radio de explosión de los incidentes»), mientras que Experimentación, al igual que las pruebas A/B, busca proporcionar una fuente continua de datos imparciales, no limitados por la disponibilidad de un analista, para indicar si cada característica logró un impacto deseado o no.
Mejor juntos: Revisión por pares, entrega progresiva y creación de sentido automatizada
¿Por qué nos esforzamos por lograr la fluidez? No se trata de la producción. Se trata de los resultados. Nos esforzamos por la fluidez para poder iterar el bucle de retroalimentación de la idea -> implementación -> observación con menos fricción en menos tiempo. Ya sea que lo llamemos «desarrollo impulsado por el impacto» o «desarrollo impulsado por el cliente», este enfoque para avanzar más rápido con una mayor (y más rápida) conciencia de los resultados va mucho más allá de la «tubería de despliegue para detectar y rechazar los malos cambios» que el equipo de DORA recomendó que combináramos con las prácticas de revisión por pares. Sí, podemos detectar y rechazar automáticamente los malos cambios, pero lo más importante es que podemos construir un proceso repetible para triangular hacia resultados empresariales significativos.
Aprenda más sobre cómo lograr la gestión del cambio y el flujo, juntos, en la entrega continua
- Vea un vídeo de cuatro minutos sobre la definición de entrega continua para ver por qué el tamaño pequeño de los lotes es fundamental para lograr un flujo consistente.
- Aproveche los consejos de varios equipos que envían a producción diariamente en el libro electrónico de O’Reilly, Continuous Delivery in the Wild
- Vea un vídeo en profundidad con Craig Sebenik (LinkedIn, Crunchbase, Matterport) sobre los beneficios de pasar a un desarrollo basado en el tronco.
¿Busca más contenido excelente sobre cómo lograr resultados significativos con la entrega de características a escala? Marque el blog de Split, visítenos en YouTube o síganos en Twitter @splitsoftware.