Por qué la implementación de DevOps a menudo no tiene éxito (y cómo puede solucionarlo)

Este artículo fue publicado originalmente en DevOps.com. Ha sido actualizado y modificado.

Al igual que "blockchain", "big data" y "disrupción digital", el término "DevOps" es otra de las palabras de moda que se lanzan actualmente en los departamentos de TI de las grandes organizaciones.

Muchos han identificado (correctamente) la necesidad de ciclos de vida de desarrollo de software más rápidos; un proceso más preciso que esté estrechamente alineado con los objetivos de negocio, permitiendo un flujo de trabajo más claro y la colaboración entre los equipos de desarrollo y de operaciones. DevOps es esencialmente el desarrollo "ágil", todo crecido y listo para asumir las necesidades de innovación constante y despliegue rápido de la empresa moderna. Para los profesionales de la seguridad, es una iniciativa fantástica: podemos inyectar la seguridad en el proceso mucho antes, reduciendo el coste de la corrección de errores y evitando posibles catástrofes en el futuro.

El problema es que pocas empresas tienen verdadero éxito en su implementación de DevOps. Sin el apoyo, el fomento y la comprensión adecuados en toda la empresa, puede convertirse rápidamente en un elefante blanco... ya sabes, uno de esos proyectos "no menciones la guerra".

Entonces, ¿cuál es el problema? Es un debate interesante, y hay algunas maneras de enfocar DevOps que creo que harán que la navegación sea mucho más suave. Un programa eficaz va más allá de unas cuantas herramientas nuevas y elegantes, títulos y reuniones de equipo. No siempre va a ser fácil, pero tomarse el tiempo para arreglar una estrategia rota (o implementarla de la manera correcta al principio) va a ser mucho menos doloroso a largo plazo. Y, en última instancia, va a dar lugar a un software de mayor calidad y más seguro.

Vamos a desglosarlo:

Suelta las amarras del delantal "Ágil".

Existe la idea errónea de que una organización debe elegir entre Agile o DevOps, y emprender un camino u otro para no volver a mirar atrás.

La cuestión es que el proceso de desarrollo funciona mejor cuando ambos se consideran e implementan como uno solo. DevOps no es una reinvención del desarrollo ágil, sino una extensión del mismo. Las ruedas tienden a caerse cuando se espera que el proceso sea exactamente como Agile, o completamente diferente de Agile.

Agile apoya el principio de los equipos interfuncionales, reuniendo a diseñadores, probadores y desarrolladores desde el principio y comprometiéndose a mantener líneas de comunicación abiertas a lo largo de un proyecto. Su objetivo es acabar con la entrega en silos y reducir la doble manipulación, ventajas ambas del proceso DevOps también. Sin embargo, DevOps va un paso más allá, introduciendo sistemas, seguridad y operaciones en la mezcla para ofrecer un sólido conjunto de habilidades de extremo a extremo que tiene como objetivo final la entrega de software completo y funcional al cliente.

Durante los inevitables puntos de dolor al pasar a un proceso más centrado en DevOps, el riesgo de desarrollo en silos puede surgir de nuevo. A menudo se puede tener al equipo original de Agile trabajando juntos, con las adiciones de seguridad y operaciones todavía encontrando su camino en la máquina; nadie está muy seguro de cómo incluirlos, lo que deberían estar haciendo y sus objetivos generales.

DevOps no funciona sin unos objetivos claramente definidos, una incorporación interfuncional y una comunicación directa con todas las partes. Habrá un período de ajuste que requerirá una gestión cuidadosa del cambio, sin duda, pero conseguir que todos estén de acuerdo con las mejoras que aportará la funcionalidad de DevOps es la mitad de la batalla.

Cada vez más (gracias a Dios), DevOps está poniendo énfasis en las mejores prácticas de seguridad como parte del proceso también, desmitificando ese paso y cerrando la brecha entre el equipo de seguridad y, bueno, todos los demás. Como he dicho antes, todavía tenemos un largo camino que recorrer para capacitar a los desarrolladores para codificar de forma segura desde el principio, pero la implementación exitosa de las metodologías DevOps es una excelente base sobre la que se pueden construir habilidades de seguridad dentro del equipo de desarrollo.

La automatización no lo es todo (y no es lo más seguro).

Otra característica de la metodología DevOps es, hasta cierto punto, la automatización del proceso de desarrollo de software. Los principios de integración continua y entrega continua (CI/CD) son las piedras angulares de este concepto y, como probablemente se puede adivinar, dependen mucho de las herramientas.

Las herramientas son increíbles, realmente lo son. Pueden aportar una velocidad sin precedentes al proceso de entrega de software, gestionando el repositorio de código, las pruebas, el mantenimiento y los elementos de almacenamiento con una facilidad relativamente perfecta.

Sin embargo, aunque los robots podrían quitarnos todos los puestos de trabajo y encarcelarnos algún día, definitivamente aún no han llegado. La gran dependencia de las herramientas y la automatización deja una ventana abierta a los errores. Es posible que los análisis y las pruebas no lo detecten todo, que el código quede sin revisar y que eso plantee enormes problemas de calidad (por no hablar de seguridad) en el futuro. Un atacante sólo necesita una puerta trasera que explotar para robar datos, y renunciar al elemento humano en el control de calidad y seguridad puede tener consecuencias desastrosas.

El "término medio" es asegurarse de tener un equilibrio entre personas y herramientas. Las herramientas deben servir de ayudantes de un equipo en el que confíes para cumplir los objetivos del proyecto. Deberían:

• Asignar el tiempo suficiente para que el personal se familiarice con la cadena de herramientas DevOps elegida
• Centrarse en la colaboración eficaz (y en cómo las herramientas pueden apoyarla)
• Abordar cualquier carencia en el proceso, ya sea de habilidades/conocimientos o de herramientas.

En resumen, no te limites a "ponerte las pilas" y esperar lo mejor.

DevOps no es una palabra de moda, es una cultura. Estás haciendo crecer la tuya?

La gestión del cambio es difícil en el mejor de los casos. El miedo a lo desconocido puede impedir que incluso los miembros más brillantes del equipo hagan crecer sus habilidades y amplíen sus horizontes.

Verás, decir simplemente "vamos a hacer DevOps" y hacer que el equipo de operaciones cambie de mesa no va a implementar mágicamente un proceso exitoso. Muchos se sentirán confundidos, y los miembros del equipo que llevan mucho tiempo en él se sentirán descontentos. La comunicación de las expectativas es crucial, al igual que "andar el camino". DevOps representa un movimiento cultural tanto como una metodología de desarrollo, y un equipo debe vivir y respirar una mentalidad interfuncional y colaborativa.

¿Cómo es una gran cultura DevOps?

• Los individuos están capacitados para aportar su experiencia a un proceso, no sólo los líderes
• Comunicación abierta, honesta y respetuosa entre los equipos
• Cada persona asume la responsabilidad del objetivo general de incorporar la calidad y la seguridad en el proceso de desarrollo
• Todo el mundo está en la misma página con la definición de DevOps en la empresa, la hoja de ruta y el cómo/qué/por qué del papel de cada persona.

Durante años he hecho hincapié en la importancia de crear culturas de seguridad positivas en los equipos de desarrollo, y DevOps no es diferente.

Las herramientas, los conocimientos y el apoyo adecuados son imprescindibles para lograr las mejores prácticas de seguridad, ver un descenso en las vulnerabilidades descubiertas y abrir los ojos del equipo a la importancia de proteger nuestros datos. Con DevOps, hay que sentar las bases culturales para un cambio positivo: asegurarse de que todo el mundo entiende su papel, su valor y sus expectativas, los objetivos generales del proyecto y los pasos del proceso.

¿Lo dominas? Muy bien. Ahora, cambiemos la aguja, marquemos el aspecto de la seguridad y hagamos de DevSecOps el plan definitivo para la excelencia del software.