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:
- 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.
- 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.
- 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.
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í.
