¿Qué contiene una "Transformación DevOps"?

Algunas empresas de consultoría están promoviendo un servicio llamado "Transformación DevOps". Varias grandes empresas están hablando sobre el tema en conferencias y reuniones en todo el mundo.

¿Qué implica tal "Transformación DevOps"? ¿Cómo se ve en términos procesables, tanto para transformaciones exitosas como fallidas?

Necesito poner mi respuesta a esta pregunta en el contexto de lo que es DevOps, más específicamente dentro de las transformaciones de DevOps de las que he formado parte, DevOps es propiedad del ciclo de vida completo de desarrollo de software. Todas las prácticas en la tabla son una parte importante de DevOps, y permiten y apuntalan tanto el pensamiento de sistemas como la amplificación de los bucles de retroalimentación .

Sin embargo, el diferenciador clave entre CI / CD y DevOps es la operación real del software en un entorno de producción, donde puede ofrecer valor a sus clientes y al negocio al que sirve.

Como consultor que participa o lidera una transformación de DevOps, tengo los siguientes aspectos en mente:

• Cultura : Como Dave señaló con razón, una Cultura de Experimentación y Aprendizaje Continuos es crítica para el éxito de cualquier transformación. Desde la perspectiva de DevOps, esto se reduce a cómo engendramos una cultura que apoye el modelo DevOps elegido, este modelo podría ser "You Build It, You Run It" o podría estar más en la línea de la práctica de Ingeniería de Confiabilidad del Sitio de Google .

• Modelo operativo : Esta es la parte de la propuesta de negocios que articula cómo la organización entregará valor, generalmente articulando las personas, los procesos y las herramientas utilizadas vinculadas en un alto nivel. Sin un modelo operativo, no tiene un plan para la forma en que la organización adopta las prácticas que define la cultura, esto, a su vez, conduce a una falta de claridad y comportamientos divergentes.

• C-Level Aircover : a menudo es nuestro trabajo como consultores que trabajan en programas de transformación hacer cambios radicales en la forma en que funcionan los negocios. Vas a molestar a las personas, y a algunas personas no les gustarán los cambios; es importante que tengas una "cubierta de aire" desde arriba para cambiar las cosas y avanzar.

Una vez que el nivel alto está en su lugar, es importante encontrar algo que pueda entregar de manera realista:

1. Comience lo más pequeño posible, idealmente, una vez que tenga algunas personas que entiendan la cultura, un bosquejo de un modelo operativo y la aceptación de los ejecutivos crean el "Proyecto mínimo viable", no intente hervir el océano introduciendo DevOps a una audiencia de miles. Establecer un objetivo alcanzable:
   • Automatice la creación de la infraestructura del Producto X.
   • Automatice la entrega del Producto X en Azure en todos los entornos.
   • Apoyo manual del subcontratista Y a un equipo de desarrollo en Londres.
   • Cree un conjunto de pruebas en torno a nuestra característica más riesgosa y ejecútelas en una integración continua.
2. Es genial que tengas algo de éxito ahora, es hora de comenzar a integrar esto en más equipos, agregar otro par de equipos a la mezcla y ponerlos en funcionamiento. No tenga miedo de ofrecer "Soporte de guantes blancos" al principio para ayudarlos en la transición; necesitarán mucha mano durante las próximas semanas y meses.
3. Ahora tiene varios de los primeros en adoptar una nueva forma de trabajar; tienes una masa crítica, es hora de comenzar a evangelizar el trabajo que estás haciendo con un público más amplio:
   • Realice sesiones regulares de mostrar y contar y solicite a los primeros usuarios que demuestren cuán exitosos han sido.
   • Ofrezca sesiones para permitir que otras partes de la organización exploren cómo pueden unirse a su equipo.
   • Permita la creación de comunidades de práctica centradas en disciplinas específicas: implementación continua, pruebas automatizadas, comunicación empresarial, gestión de riesgos, monitoreo y alerta, etc.

4. Mantenga el rumbo y cierre la transformación incorporando al resto de la organización. Comprender la relación entre el ciclo de bombo de Gartner y el ciclo de vida de la adopción . Prepárese para que el Programa de transformación caiga en el "valle de la desilusión", mantenga el rumbo y mantenga a la vista el objetivo final.

   

Para una exploración más profunda del punto final, lea Cruzando el abismo de Geoffrey A. Moore . Literalmente, podría escribir un libro sobre cómo entregar una transformación DevOps, sin embargo, para cuando lo haya terminado, probablemente no habrá más trabajo de transformación DevOps para mí.

DevOps tiende a dividirse en tres dimensiones principales:

Cultura La
cultura de DevOps enfatiza los altos niveles de confianza, colaboración y comunicación entre todos los interesados, especialmente Dev, Ops y Seguridad. La tensión natural y la competencia entre estos grupos crea fricción y, a menudo, disfunción. DevOps es (posiblemente) ante todo acerca de alinear los esfuerzos entre estos equipos.

Procesos Los
procesos de desarrollo DevOps se alinean estrechamente con los procesos ágiles. Se alienta a Ops a adoptar prácticas similares a Agile para alinearse mejor con los esfuerzos de Dev. Los procesos alineados con DevOps están diseñados para admitir ciclos de retroalimentación rápidos y de alta velocidad a lo largo de los ciclos de vida de desarrollo / entrega. La integración continua, la entrega continua y la mejora continua (kaizen) son áreas de enfoque del proceso DevOps.

La tecnología
DevOps no es una herramienta, pero es compatible con herramientas. Hay familias enteras de herramientas que admiten una variedad de áreas, incluida la integración continua, el control de origen y la gestión del ciclo de vida de la aplicación.

Una "Transformación DevOps" debe abordar elementos de los tres, pero no necesariamente todos por igual al mismo tiempo. Hay una progresión natural y un "camino crítico" para la transformación. El argumento podría hacerse, por ejemplo, DevOps depende de alguna forma de práctica ágil, al menos dentro del equipo / equipos de desarrollo. Es posible que sea necesario abordar los problemas con la cultura antes de realizar inversiones en herramientas.

Referencias:
Cultura: https://www.andykelk.net/devops/using-the-westrum-typology-to-measure-culture
Tecnología: https://xebialabs.com/periodic-table-of-devops-tools/