DevOps

Desde la fusión de Desarrollo (Dev) y Operaciones (Ops), DevOps es el siguiente paso natural de Agile.

El primer manifiesto de desarrollo de software[1]Agile ya lo dejó claro: “our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. Entrega rápida y continua de software que aporte valor a las empresas.

Esta parece una proposición neutra y universalmente válida, hasta nos damos cuenta de lo distante que está de las prácticas habituales de otras organizaciones.

La relación entre las tecnologías de información (o IT) y las operaciones (de negocio) nunca fue pacífica. Representado por departamentos de sistemas de información internos o por proveedores externos, el IT tradicional (pre-devOps) ha asumido posiciones poco flexibles, tardando mucho tiempo en responder a los deseos de las áreas que utilizan sus soluciones.

Y las áreas operativas tienden a no transferir su conocimiento de procesos y prácticas para el IT, siendo cierto que, la mayoría de las veces, el IT tradicional no aprecia y reacciona negativamente a estas sugerencias, que considera «excesiva» personalización^[2].

En el flujo continúo de creación de valor para el cliente, es necesario una mejor colaboración entre las muchas funciones involucradas, es decir, una reingeniería de procesos que incluya también el IT.

DevOps aboga por la constitución de equipos conjuntos y directos, solidariamente responsables, sin intervención de terceros.

Los terceros habitualmente convocados (Quality Assurance^[3], una coordinación, una fiscalización del proyecto) para crear un puente entre Dev y Ops, en la práctica destruyen la nueva relación de confianza que la cultura DevOps pretende establecer entre el desarrollo y las operaciones. Y destruyen, inevitablemente, porque su única razón de existencia es que el supuesto de esa confianza está ausente^[4].

La organización ya no se mira a nivel de proyecto, sino como un servicio continuo que

• Detecta (e incluso predice) las nuevas necesidades del cliente y modela los nuevos requisitos.
• Las traduce rápida e inmediatamente en código.
• Integra, prueba y garantiza la coherencia de todos los componentes y el trabajo paralelo desarrollado por el equipo
• Entrega la nueva versión al cliente.
• (A petición o después de la validación) pone la nueva versión en uso productivo para negocios / operaciones (Ops).

La comunidad DevOps, bastante fuerte, organiza todos los años el All Day DevOps, un evento que, seguramente, vale la pena seguir. Mientras llega el de 2018, merece la pena asistir a las 100 sesiones de 2017^[5].

El informe de Puppet sobre el estado actual de DevOps (2018 State of DevOps Report)^[6] es también una referencia útil.

La contribución de Quidgest

Genio es único en el nivel de automatización de este proceso. Sin él, DevOps sufre limitaciones

• la integración continua no incluye la fase de exploración de nuevos requisitos.
• ni puede modelarlos.
• por otra parte, la exploración, modelado e integración continuas requerirían un esfuerzo considerable para programar manualmente, siendo un hecho que la codificación manual obstruye los flujos de DevOps y pone en peligro sus resultados.

El flujo de DevOps puede ser más lento o más rápido. Obviamente, el objetivo es hacerlo lo más rápido posible. No vale la pena que una empresa diga que ha adoptado esta metodología si los tiempos de las versiones mejoradas por el desarrollo (Dev) a las operaciones (Ops) son demasiado largos.

Genio de Quidgest contribuye drásticamente al éxito de esta metodología, ya que interconecta todo el proceso:

• Modela los requisitos.
• Programa el código automáticamente y extremadamente rápido.
• Integra el trabajo de varios equipos (a través de GenioSVN).
• Prepara, prueba y entrega (a través de herramientas de código abierto como Jenkins, ya que solo usamos lenguajes de codificación estándar).
• Se asegura de que la estructura de datos evolucione automáticamente y documente, informe y prepare a los usuarios finales para garantizar el uso productivo de las nuevas versiones.

DevOps requiere de la existencia de architecturally significant requirements. En Quidgest, esos requisitos fueron transformados en patrones, constituyendo un conjunto de patrones relacionados con la ingeniería de software.

El proceso de integración requiere una herramienta para controlar las versiones (en Quidgest, Genio SVN), con todas las funcionalidades asociadas a los repositorios, checkout, baselines, updates, commits, gestión de conflictos, lista de cambios, branches o forks, revisión mutua y responsabilización (blame).

Genio apoya otro aspecto importante, las evoluciones paralelas de ambas capas del modelo: modelo de negocio (estructura de datos, reglas de negocio, interfaces y procesos) y tecnología (arquitecturas, lenguajes de programación, bibliotecas y patrones).

En un proceso de integración continúa, la evolución lo es también. Lo que garantiza 1) vidas útiles de las soluciones más prolongadas y 2) la inexistencia de interrupciones en el cambio de las versiones del software.

Nuestros clientes y socios de co-innovación, especialmente los que hemos otorgado este año, muestran un claro ejemplo de aplicación práctica de DevOps a sistemas de información complejos.

___________________

[1] http://agilemanifesto.org/principles.html
[2] A revista QuidNews nº 10 ilustrava, com uma pequena história “O aleijadinho e o alfaiate”, a páginas 25, o que a Quidgest pensa deste conceito de excessiva customização.
[3] O diagrama que, a esta data, ainda figura na página wiki correspondente https://en.wikipedia.org/wiki/DevOps#/media/File:Devops.svg ainda inclui o QA na equação, o que não nos parece fazer qualquer sentido
[4] Uma posição muito próxima é defendida por Asaf Yigal https://devops.com/devops-killed-qa/
[5] Disponíveis em https://www.alldaydevops.com/2017-all-day-devops-video-recordings Por exemplo “It’s Not Continuous Delivery If You Can’t Deploy Right Now”, por Ken Mugrage
[6] Acabado de publicar, a 12 de setembro