Debería desplegarse más a menudo
DevOps Research and Assessment(
DORA) es un programa de investigación, actualmente dirigido por Google, que pretende medir y comprender el rendimiento de las operaciones y la entrega de software. Desde 2014, DORA realiza una encuesta anual entre los profesionales del software de diferentes organizaciones y, a continuación, publica su
informe Accelerate State of DevOps Report. Estos informes no solo muestran los resultados de la encuesta, sino que también exponen los factores que afectan al rendimiento y el bienestar del equipo, y las prácticas que se recomiendan o desaconsejan.
Probablemente, la conclusión más destacada de la investigación DORA es que el rendimiento de la entrega de software de una organización puede predecirse mediante cuatro métricas muy sencillas:
Probablemente, la conclusión más destacada de la investigación DORA es que el rendimiento de la entrega de software de una organización puede predecirse mediante cuatro métricas muy sencillas:
- Frecuencia de despliegue: ¿Con qué frecuencia se despliega el software en producción?
- Plazo de cambio: ¿Cuánto tarda un cambio de código en llegar a producción?
- Cambiar el porcentaje de fallos: Cuando se produce un despliegue, ¿qué probabilidades hay de que falle o se revierta?
- Tiempo para restablecer el servicio: Cuando se detecta un fallo en producción, ¿cuánto tarda en solucionarse en producción?
El modelo central de DORA
A grandes rasgos, podemos decir que aquí se miden dos rasgos del producto: Las dos primeras métricas evalúan
la velocidad de entrega del software. Los dos últimos tratan de
la estabilidad del software suministrado.
(Nota: A partir de 2021, el DORA considera la fiabilidad como una quinta métrica que mide el rendimiento operativo)
Intuitivamente, estas dos cosas parecen estar en oposición: Cuando tenemos miedo a cometer errores, nuestro instinto es ir más despacio. Traducido a la entrega de software, esto significaría que desplegar en producción con menos frecuencia conlleva menos errores. Es habitual que un incremento de software de mala calidad se retrase hasta que se resuelven los problemas.
Sin embargo, los descubrimientos del equipo DORA desmienten esta intuición. En el último informe, los equipos se agrupan en tres grupos con un rendimiento Bajo, Medio y Alto (en informes anteriores había un cuarto grupo denominado Elite). El grupo de bajo rendimiento se despliega entre una y dos veces al año, y al mismo tiempo comete errores alrededor de la mitad de las veces. El grupo de alto rendimiento se despliega varias veces al día con un índice de errores del 15 % o menos.
Es decir, velocidad y estabilidad están directamente correlacionadas, no a la inversa. Los equipos de alto rendimiento son rápidos y fiables, mientras que los de bajo rendimiento son más lentos a la hora de aportar valor y también más propensos a cometer errores.
Por otra parte, los equipos que cumplen de forma lenta pero segura, o a la inversa, rápidos pero con errores, son la excepción y no la regla.
¿Cómo es posible?
La razón más probable es que un ritmo de despliegue más rápido exige del equipo de software muchas buenas prácticas que benefician tanto a la velocidad como a la estabilidad.
(Nota: A partir de 2021, el DORA considera la fiabilidad como una quinta métrica que mide el rendimiento operativo)
Intuitivamente, estas dos cosas parecen estar en oposición: Cuando tenemos miedo a cometer errores, nuestro instinto es ir más despacio. Traducido a la entrega de software, esto significaría que desplegar en producción con menos frecuencia conlleva menos errores. Es habitual que un incremento de software de mala calidad se retrase hasta que se resuelven los problemas.
Sin embargo, los descubrimientos del equipo DORA desmienten esta intuición. En el último informe, los equipos se agrupan en tres grupos con un rendimiento Bajo, Medio y Alto (en informes anteriores había un cuarto grupo denominado Elite). El grupo de bajo rendimiento se despliega entre una y dos veces al año, y al mismo tiempo comete errores alrededor de la mitad de las veces. El grupo de alto rendimiento se despliega varias veces al día con un índice de errores del 15 % o menos.
Es decir, velocidad y estabilidad están directamente correlacionadas, no a la inversa. Los equipos de alto rendimiento son rápidos y fiables, mientras que los de bajo rendimiento son más lentos a la hora de aportar valor y también más propensos a cometer errores.
Por otra parte, los equipos que cumplen de forma lenta pero segura, o a la inversa, rápidos pero con errores, son la excepción y no la regla.
¿Cómo es posible?
La razón más probable es que un ritmo de despliegue más rápido exige del equipo de software muchas buenas prácticas que benefician tanto a la velocidad como a la estabilidad.
Debes seguir mejorando
Como ya se ha dicho, el informe DORA no solo muestra los resultados de las encuestas, sino que también proporciona ideas y consejos. Una de estas ideas es que los equipos que se adaptan y mejoran continuamente tienen un mejor rendimiento. En este caso, las pruebas empíricas respaldan la idea intuitiva de que la mejora continua es el camino hacia los mejores resultados.
Una vez que tengas una mentalidad de mejora continua, debes decidir qué objetivo persigues y qué métrica vas a medir para evaluar tu mejora. La opción obvia será probablemente apostar por menos errores en producción y más funciones en cada versión. Proponemos que, aunque el objetivo final siga siendo el mismo, el equipo se centre en aumentar la velocidad de despliegue. Esto seguramente conducirá a los otros objetivos (dado que, como vimos antes, la velocidad y la estabilidad están directamente correlacionadas), pero también proporcionará un camino más claro para lograrlo.
Una vez que tengas una mentalidad de mejora continua, debes decidir qué objetivo persigues y qué métrica vas a medir para evaluar tu mejora. La opción obvia será probablemente apostar por menos errores en producción y más funciones en cada versión. Proponemos que, aunque el objetivo final siga siendo el mismo, el equipo se centre en aumentar la velocidad de despliegue. Esto seguramente conducirá a los otros objetivos (dado que, como vimos antes, la velocidad y la estabilidad están directamente correlacionadas), pero también proporcionará un camino más claro para lograrlo.
Sea cual sea tu situación...
Hay varios factores que pueden limitar la frecuencia de despliegue de un equipo, más allá de su capacidad para proporcionar el código:
Por otra parte, es probable que tu equipo aún no haya alcanzado el límite de velocidad absoluto que tu situación te permite en cada circunstancia. Por ejemplo: Es posible que puedas implantar cambios en una aplicación iOS en dos días, que suele ser el tiempo necesario para el proceso de la revisión. Pero, cuando se recibe un asunto de la revisión, ¿necesita otro par de días? Otra situación: Puede que tu cliente solo acepte cambios en versiones bimensuales. Pero cuando aparece un fallo grave en producción, ¿cuánto tiempo se necesita para tener una solución lista para desplegar?
- Limitaciones de la plataforma: La plataforma que vaya a ejecutar el software determinará la frecuencia con la que puede desplegarse. Algunos ejemplos: Una aplicación web puede modificarse tantas veces como se desee, y los usuarios pueden ver inmediatamente el cambio. Una versión actualizada de una aplicación para iOS requiere una revisión por parte de Apple, que puede tardar varios días. Actualizar el software integrado en un coche puede requerir una visita al taller. El código de una tarjeta de crédito no se cambia nunca.
- Límites empresariales u organizativos: Una empresa o unidad de negocio puede producir el software que luego se entrega a otra distinta para que lo instale y gestione en sus instalaciones. Por tanto, el equipo que crea el software pierde el control del proceso.
- Falta de confianza: Un historial de despliegues anteriores fallidos y errores costosos en producción puede hacer que todas las partes teman los cambios, haciendo que las implantaciones en producción sean menos frecuentes. Esto desencadena un círculo vicioso en el que los plazos de publicación más largos hacen que se publiquen cambios más grandes y complejos, lo que aumenta la probabilidad de que se produzcan errores, y así sucesivamente.
Por otra parte, es probable que tu equipo aún no haya alcanzado el límite de velocidad absoluto que tu situación te permite en cada circunstancia. Por ejemplo: Es posible que puedas implantar cambios en una aplicación iOS en dos días, que suele ser el tiempo necesario para el proceso de la revisión. Pero, cuando se recibe un asunto de la revisión, ¿necesita otro par de días? Otra situación: Puede que tu cliente solo acepte cambios en versiones bimensuales. Pero cuando aparece un fallo grave en producción, ¿cuánto tiempo se necesita para tener una solución lista para desplegar?
... Hay una forma
Antes hemos admitido que lo que la mayoría de los equipos quieren mejorar es el número de funciones entregadas y la calidad de la entrega (en número de errores). Pero ir a por ellos directamente significa una postura pasiva y reactiva. Para reducir los fallos, deberías haber prestado más atención, haber hecho pruebas más exhaustivas o haber pensado en tal o cual consecuencia imprevista. Para entregar más deberías haber codificado más rápido. Es difícil tener un plan para mejorar la situación desde este punto de vista.
La otra forma de pensar en esto es que el objetivo a largo plazo debería ser hacerlo tan bien como los equipos de alto rendimiento. Estos equipos son capaces de realizar varios despliegues al día, así que deberíamos avanzar hacia ese nivel de eficiencia.
Desplegar más rápido no significa simplemente establecer un calendario de despliegue más rápido y seguirlo a rajatabla. Sin duda esto acabará mal. Más bien debemos analizar nuestro proceso, detectar los cuellos de botella y eliminarlos de forma iterativa, para que el equipo se sienta naturalmente más seguro y cómodo aumentando la velocidad.
Estos cuellos de botella sugerirán los siguientes pasos que hay que dar para permitir la aceleración. A continuación se ofrece una enumeración, sin duda incompleta, de las situaciones en las que puede encontrarse un equipo y de las técnicas que pueden emplearse para resolverlas. La definición exacta de estas prácticas queda fuera del alcance de este escrito, pero se espera que despierten la curiosidad del lector. Más información en las referencias al final.
No hemos mencionado las prácticas populares de IC/DC, que pueden definirse del siguiente modo:
IC: Integración continua. La práctica de integrar código en la rama principal del repositorio al menos una vez al día, cada confirmación desencadena una compilación del código y un conjunto de pruebas automáticas.
DC: Esto puede significar Despliegue Continuo o Entrega Continua (que de hecho se menciona como una de las prácticas recomendadas), que no son lo mismo. Despliegue continuo significa que cada confirmación se despliega automáticamente en producción sin intervención manual. La Entrega Continua es más relajada y significa que el código está en todo momento preparado para ser desplegado bajo demanda.
Estas son dos prácticas más amplias, que requieren para funcionar, de muchas de las técnicas mencionadas anteriormente (pruebas automáticas, canalización de despliegue automático, ramas de vida corta), por lo que no se adaptan tan bien a un enfoque de pequeños pasos. Sin embargo, pueden considerarse un hito intermedio o un requisito más general para alcanzar despliegues más rápidos.
Tampoco hemos mencionado otras buenas prácticas básicas que los desarrolladores deben seguir incluso antes de considerar las técnicas recomendadas, que consideramos prácticas ya aceptadas en el panorama actual de la codificación, y necesarias para una mejor experiencia de desarrollo en general, así como para un ritmo de despliegue más rápido. Algunas de ellas son el control de versiones del código mediante herramientas como git, entornos múltiples (desarrollo y producción, por ejemplo), convenciones de codificación para todo el equipo, etc.
La otra forma de pensar en esto es que el objetivo a largo plazo debería ser hacerlo tan bien como los equipos de alto rendimiento. Estos equipos son capaces de realizar varios despliegues al día, así que deberíamos avanzar hacia ese nivel de eficiencia.
Desplegar más rápido no significa simplemente establecer un calendario de despliegue más rápido y seguirlo a rajatabla. Sin duda esto acabará mal. Más bien debemos analizar nuestro proceso, detectar los cuellos de botella y eliminarlos de forma iterativa, para que el equipo se sienta naturalmente más seguro y cómodo aumentando la velocidad.
Estos cuellos de botella sugerirán los siguientes pasos que hay que dar para permitir la aceleración. A continuación se ofrece una enumeración, sin duda incompleta, de las situaciones en las que puede encontrarse un equipo y de las técnicas que pueden emplearse para resolverlas. La definición exacta de estas prácticas queda fuera del alcance de este escrito, pero se espera que despierten la curiosidad del lector. Más información en las referencias al final.
- Las historias de usuario tardan demasiado en completarse: Elaboración de historias de usuario más cortas. Rebanar (dividir un US grande en trozos más pequeños). Mejorar la arquitectura para facilitar los cambios. Permitir el despliegue a producción de código para características aún no terminadas (ramificación por abstracción, conmutación de funciones)
- Los codificadores suelen estar bloqueados a la espera de revisiones: Programación en parejas. Revisiones posteriores al compromiso.
- Aparecen muchos errores en producción y/o durante la fase de control de calidad: Más pruebas unitarias. Desarrollo basado en pruebas (TDD). Automatización de pruebas en general. Balas de rastreo (versiones mínimas de una función que tocan todas las partes de los sistemas afectados, para que todos los problemas salgan pronto a la luz). Conmutación de funciones (permite prácticas como el lanzamiento oscuro, o el lanzamiento canario, que hacen más seguro el lanzamiento de nuevas funciones, y también permite desactivar las funciones que se están comportando mal, mientras que el resto del servicio sigue funcionando).
- Al final del periodo, todas las funciones se integran al mismo tiempo, lo que provoca muchos conflictos: Desarrollo basado en troncos, o al menos en ramas de corta duración. Desacoplar la fusión del código de la finalización de una función. Rebanar. Programación por parejas y programación de conjuntos (Mob).
- Los requisitos de los productos cambian constantemente: Conmutación de funciones. Rebanar. Entrega continua (la cabeza de la rama principal siempre está lista para ser desplegada en producción. Véase más abajo).
- Los errores tardan demasiado en resolverse: Pruebas unitarias y desarrollo dirigido por pruebas (TDD). Entrega continua.
- Los despliegues suelen acabar en fracaso: Automatización del proceso de implantación
Los despliegues requieren mucho trabajo adicional: Automatización del proceso de implantación. Documentación automática.
No hemos mencionado las prácticas populares de IC/DC, que pueden definirse del siguiente modo:
IC: Integración continua. La práctica de integrar código en la rama principal del repositorio al menos una vez al día, cada confirmación desencadena una compilación del código y un conjunto de pruebas automáticas.
DC: Esto puede significar Despliegue Continuo o Entrega Continua (que de hecho se menciona como una de las prácticas recomendadas), que no son lo mismo. Despliegue continuo significa que cada confirmación se despliega automáticamente en producción sin intervención manual. La Entrega Continua es más relajada y significa que el código está en todo momento preparado para ser desplegado bajo demanda.
Estas son dos prácticas más amplias, que requieren para funcionar, de muchas de las técnicas mencionadas anteriormente (pruebas automáticas, canalización de despliegue automático, ramas de vida corta), por lo que no se adaptan tan bien a un enfoque de pequeños pasos. Sin embargo, pueden considerarse un hito intermedio o un requisito más general para alcanzar despliegues más rápidos.
Tampoco hemos mencionado otras buenas prácticas básicas que los desarrolladores deben seguir incluso antes de considerar las técnicas recomendadas, que consideramos prácticas ya aceptadas en el panorama actual de la codificación, y necesarias para una mejor experiencia de desarrollo en general, así como para un ritmo de despliegue más rápido. Algunas de ellas son el control de versiones del código mediante herramientas como git, entornos múltiples (desarrollo y producción, por ejemplo), convenciones de codificación para todo el equipo, etc.
No esperes a nadie
Como miembro de un equipo de desarrollo, puede que estés convencido de todo lo que se ha dicho aquí, pero aun así, te sientes incapaz de convencer al equipo o al cliente para que desplieguen más rápido. O puede que te encuentres en alguna de las situaciones mencionadas anteriormente, que hacen imposible una entrega más rápida. Aun así, no estás indefenso. Puede darle la vuelta y empezar con las técnicas mencionadas, para estar preparado para desplegar más rápidamente cuando llegue la oportunidad.
Sea cual sea tu papel en el equipo (desarrollador, producto, control de calidad), siempre hay alguna técnica que puedes aprender, adoptar o ayudar a adoptar. Además, no hace falta que convenzas a todo el equipo para empezar, siempre puedes avanzar en esta dirección tú mismo, en las tareas que vayas asumiendo. No necesitas permiso para hacer mejor tu trabajo.
Cuantas más de estas técnicas estén en marcha, más fácil será que el producto se despliegue más rápido y mejor idea parecerá. Sé paciente, trata de escuchar las necesidades y problemas de los demás interesados, y luego intenta resolverlos. Seguramente estarán encantados de entregar valor más rápido cuando sientan que es seguro. E incluso antes de que eso ocurra, cuando surja una emergencia, como una revisión o una solicitud de una función que "no puede retrasarse", verás recompensados tus esfuerzos.
Sea cual sea tu papel en el equipo (desarrollador, producto, control de calidad), siempre hay alguna técnica que puedes aprender, adoptar o ayudar a adoptar. Además, no hace falta que convenzas a todo el equipo para empezar, siempre puedes avanzar en esta dirección tú mismo, en las tareas que vayas asumiendo. No necesitas permiso para hacer mejor tu trabajo.
Cuantas más de estas técnicas estén en marcha, más fácil será que el producto se despliegue más rápido y mejor idea parecerá. Sé paciente, trata de escuchar las necesidades y problemas de los demás interesados, y luego intenta resolverlos. Seguramente estarán encantados de entregar valor más rápido cuando sientan que es seguro. E incluso antes de que eso ocurra, cuando surja una emergencia, como una revisión o una solicitud de una función que "no puede retrasarse", verás recompensados tus esfuerzos.
Conclusión
Las pruebas empíricas sugieren que la velocidad de entrega y la estabilidad del software no se oponen entre sí, sino que están directamente correlacionadas. Teniendo en cuenta esta observación, proponemos que, incluso si el objetivo de tu equipo es reducir el número de errores y entregar más funciones, es una buena idea dirigir tus esfuerzos a desplegar más a menudo. Esta decisión aconsejará la adopción de prácticas y revelará cuestiones que ayudarán al rendimiento del equipo de muchas maneras.
Estas prácticas son en su mayoría técnicas y están relacionadas con la adopción de un auténtico CI/CD, pero se benefician de la participación de todas las partes interesadas del equipo e incluso de la organización. Al mismo tiempo, estas prácticas proporcionan un camino más claro para la mejora de cualquier equipo, independientemente del estado del software o de los procesos actualmente en vigor. Por tanto, estas prácticas apoyarán a cada miembro del equipo, capacitándolo para mejorar el producto.
Estas prácticas son en su mayoría técnicas y están relacionadas con la adopción de un auténtico CI/CD, pero se benefician de la participación de todas las partes interesadas del equipo e incluso de la organización. Al mismo tiempo, estas prácticas proporcionan un camino más claro para la mejora de cualquier equipo, independientemente del estado del software o de los procesos actualmente en vigor. Por tanto, estas prácticas apoyarán a cada miembro del equipo, capacitándolo para mejorar el producto.
Pruebas de Captura de Pantalla con Roborazzi en Sistemas de Diseño
Descubre cómo usamos Roborazzi para realizar pruebas de captura de pantalla eficientes en nuestros sistemas de diseño, asegurando la coherencia visual en distintas marcas y dispositivos sin la necesidad de emuladores. Aprende a integrarlo con Robolectric.