Qué es realmente DevOps?

Existen muchas definiciones para DevOps, la más simple de ellas considera DevOps el modelo de organización de equipo único capaz de desarrollar y operar de forma continua una aplicación de software, apoyada por un conjunto de herramientas que permiten secuencia y automáticamente la integración, prueba y entrada en la producción de código (como si un pipeline se tratara), donde el código, después de varias etapas de aprobación, entra en producción, constituyendo una nueva versión. En este post, intentaré compartir mi definición y algunas consideraciones personales sobre las implicaciones de decidir organizar su equipo de desarrollo en un modelo DevOps.

DevOps también se define por un ciclo de trabajo continuo, ejecutado por un único equipo, permitiendo: la definición del producto, desarrollo del producto y operación o mantenimiento de ese mismo producto. Estas tres áreas, en colaboración, contribuyen al valor del producto en interacciones continuas de retroalimentación, inspección, corrección y mejora del producto. En la perspectiva del desarrollo, esto implica la continua integración de código, pruebas continuas y la continua entrada en producción, garantizando el modelo de desarrollo continuo.La implementación de DevOps requiere inversión en una cadena de herramientas de software, pero es necesario tener disciplina para no fragmentar el conjunto de herramientas de software inicialmente planeado para apoyar el desarrollo continuo. Mantener un amplio conjunto de aplicaciones para garantizar el pipeline automatizado puede llegar a ser muy confuso, caro y difícil de mantener un escenario en el que cada equipo decida sobre su modus operandi, no respetando el conjunto de predefinido centralmente. El DevOps también puede ser considerado un medio para alcanzar el fin: impulsar la transformación Agile, la colaboración eficiente entre el equipo y entre equipos en el desarrollo conjunto de productos, la modernización de aplicaciones y una forma de migrar aplicaciones a Cloud. DevOps es también el objetivo técnico de una transformación Agile. Los ciclos continuos de DevOps aumentan el valor entregado al cliente, originando productos de mejor calidad, aumentando la productividad del equipo y su motivación gracia a la constatación de tener una capacidad de entrega independiente, en ciclos disciplinados.

Por qué tener un equipo altamente calificado durante el proceso de transición a DevOps?

Cuando organizamos un equipo de desarrollo y queremos que se vuelvan autosuficientes e independientes, necesitamos estar seguros de que tienen las competencias necesarias para definir los requisitos del producto, planearon su implementación considerando interdependencias y escenarios de complejidad incrementale, exigiendo flexibilidad de arquitectura y seguridad para mantener la integridad de los datos, garantizando el mejor rendimiento posible y la mejor experiencia de usuario. Será un desafío reunir a un equipo con estas capacidades, pero esto permitirá ciertamente alcanzar las metas de DevOps.

Planificación de DevOps

Implementar un proceso y agrupar un equipo DevOps es normalmente un proceso largo, que requiere cambios en diferentes áreas de la organización: procesos, funciones y fundamentalmente en niveles de calidad para producir e implementar software.

Estas razones exigen a los gestores y ejecutivos una permanente actualización de resultados y priorización de la hoja de ruta estratégica de implementación del plan de transición para DevOps. Este mapa de rutas debe responder a algunas preguntas:

  • Qué pretendo alcanzar al implementar el proceso de desarrollo en un modo DevOps? Más calidad? Velocidad en la respuesta a cuestiones críticas? Velocidad a mostrar resultados de la implementación? Mejor gestión del proceso de Build y Release? Mejor colaboración entre los diferentes niveles de soporte? etc …
  • En qué aplicaciones realmente tiene sentido implementar DevOps?

Cuando plantea estas cuestiones, debe tener en cuenta:

  • Complejidad de las aplicaciones: tendrá sentido migrar de arquitecturas monolíticas en aplicaciones locales para aplicaciones en Cloud con modernas arquitecturas, por ejemplo, basadas en micro-servicios.
  • Hay capacidad de inversión para ello? Refactorización? – Si se toma el ejemplo de la industria financiera, con muchas de estas aplicaciones monolíticas locales, el cambio y la inversión en devOps es grande, lento y posiblemente doloroso.

No hay una receta para un plan de transición para DevOps

No hay ingresos para un plan de transición de DevOps, es una decisión seria. Como he dicho antes, esto implica cambios profundos y costos. Mi recomendación es:

  • Analice la complejidad y la dependencia de su negocio con respecto a las aplicaciones por donde desea comenzar el proceso de DevOps;
  • Piense en la prioridad y los servicios que tienen más sentido adaptar, obteniendo mayor eficiencia y reducción de riesgo para tener una la aplicación crítica bloqueada durante un proceso de transición a DevOps.
  • Avalie si vale la pena hacer grandes cambios en la arquitectura en las plataformas antiguas o simplemente mantener el sistema funcionando de una manera elegante.
  • Haz cambios en el cambio y aprenda el cambio tras el cambio si vale la pena continuar.
  • Tal vez en su negocio no tenga sentido tener versiones continuas, sin comunicarse y entrenar de antemano a los usuarios para las nuevas características.

Medición del impacto

En algunas organizaciones, la preparación del Roadmap de transición a DevOps es una tarea muy difícil, exigiendo la inversión y el know-how, que a menudo no está disponible. Si por un lado debe planear con antelación, también debe desarrollar un plan de DevOps con metas a corto plazo, inspeccionando y corrigiendo el mismo regularmente.

Dirige el plan DevOps de una manera holística, planifica a corto plazo. La arquitectura flexible le permitirá adaptarse o corregir más rápidamente en su producto.

Dejar una respuesta

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.