A menudo hablamos sobre cómo DevOps y la automatización pueden ayudar a acelerar los ciclos de lanzamiento y obtener los últimos cambios de código y actualizaciones de una manera rápida, estable y eficiente. Esta mentalidad de DevOps mantiene a los desarrolladores y los equipos de operaciones sincronizados y garantiza que el software que producen esté siempre a la vanguardia. ¿Pero esto es demasiado?
Con un enfoque continuo en recortar el tiempo del ciclo de lanzamiento y automatizar este proceso, ¿las organizaciones de DevOps se enfocan lo suficiente en la aplicación en sí? La mentalidad de DevOps ha fomentado un programa de cambio más agresivo. ¿Es siempre por la razón correcta? Si bien este nivel de agilidad y cambio a menudo se muestra como un aspecto positivo para las empresas, cualquier cambio, grande o pequeño, afecta a los clientes.
Cuando realiza un cambio en su aplicación, es posible que el cliente deba probar y validar internamente la aplicación antes de implementarla en producción. De hecho, ese es normalmente el caso del software de nivel de producción. Si la aplicación en cuestión se actualiza mensualmente o trimestralmente, eso puede suponer una importante pérdida de recursos de sus clientes para estos procesos internos. Esta es una pieza del rompecabezas que puede perderse en la mentalidad de DevOps.
Oriente su mentalidad de DevOps en torno al usuario
Cuando practica CI / CD de alta velocidad, es su cliente quien debe gestionar estos cambios constantes. Si su equipo de DevOps realiza cambios menores y frecuentes para un efecto bajo, ¿es realmente justo esperar que sus clientes actualicen continuamente su propio software?
Cambiar por cambiar le cuesta tiempo y recursos al cliente, incluso con la automatización y los ciclos de vida rápidos. Aquellos benefician el proceso de lanzamiento, pero no necesariamente los procesos de adopción del cliente.
Esto no significa que las implementaciones de software deban volver al enfoque monolítico. Eso simplemente no fue lo suficientemente rápido, estable o eficiente, pero las organizaciones de DevOps tienen que controlar y comunicar este aspecto de cambio a sus clientes para que comprendan cómo será el ciclo de cambio. Y si no tiene un ciclo de lanzamiento definido, o si es aleatorio o se basa en cuándo están listas las actualizaciones, eso es una gran señal de alerta.
Comunicar cambios de software
Recuerde que las empresas confían en el software publicado en producción. Ese software tiene que funcionar, por lo que sus clientes tendrán controles y políticas para las actualizaciones. El argumento de que los cambios menores no causarán problemas siempre parece surgir, y solo se necesitan unas pocas búsquedas en Internet para encontrar muchos ejemplos de problemas menores que causaron interrupciones masivas. Entonces, si bien es poco común, sucede, y las organizaciones de DevOps deben tener en cuenta cómo un cambio podría afectar a sus clientes.
Por eso es tan importante que una organización de DevOps observe cualquier programa de actualización de aplicaciones y se lo comunique claramente a sus usuarios para que puedan confiar en él y comprender los beneficios y riesgos de estas actualizaciones. Eso requiere tiempo y esfuerzo, y simplemente no se puede hacer si las actualizaciones llegan demasiado rápido. Encuentra un equilibrio.
Aquí es donde entra en juego el aspecto del equilibrio. Una mentalidad de DevOps debe tener siempre un aspecto de cliente. DevOps no puede tratarse solo del proceso de lanzamiento y la automatización. Después de todo, se supone que DevOps tiene que ver con el beneficio para el usuario. Puede que tenga que reducir la velocidad, pero eso no es malo. Su código y aplicaciones deben enfocarse en el cliente. Si pierde de vista eso, ¿quién quedará para instalar todas las actualizaciones de su nueva aplicación?