Niveles de implementación de metodologías DevOps

En el último par de años, los paradigmas de la industria del desarrollo de software se han inclinado rápidamente a las metodologías DevOps, las cuales, no se puede negar, nos brindan un aumento tanto en la productividad como en la confiabilidad de nuestros procesos del ciclo de desarrollo. Eso sí, todo depende de su correcta implementación.

Como siempre se ha dicho, a la hora de buscar una solución, lo más importante es la correcta y completa identificación de cuál es el problema; así mismo pasa con DevOps. Primero debemos identificar cuál es la necesidad de nuestra organización o equipo de trabajo para posteriormente plantear los pasos a seguir hacia la adopción de DevOps.

Para esto es bastante útil realizar una autoevaluación de nuestra situación actual y darnos una clasificación o calificación y de acuerdo a esta tomar decisiones.

Cabe resaltar que en realidad no existe una receta mágica para DevOps y que cada organización y cada proyecto es diferente. Pero si existen razones para implementar DevOps en una empresa que busca ser ágil.

Aun así desde la experiencia de esta compañía, se ha realizado la siguiente clasificación a manera de guía para aquellos que piensan empezar el camino DevOps o buscan mejorar aún más.

Clasificación para la implementación de DevOps

1. Sin necesidad

No todos los equipos de trabajo requieren un modelo de trabajo orientado a DevOps. En ocasiones un equipo de trabajo puede estar compuesto por tan solo una o dos personas con un flujo de trabajo que no presentaría mayores mejoras si se adoptara una metodología diferente.

También es posible que se esté trabajando con tecnologías no muy flexibles o antiguas, donde la automatización o monitoreo están fuera de discusión.

2. Denegación de DevOps y mala interpretación

En esta categoría se percibe una incompetencia inconsciente, la falta de comprensión de qué es DevOps y cuáles son sus beneficios comerciales hace que las organizaciones nieguen la utilidad de DevOps y lo descarten como una especie de moda o mal término de marketing.

Algunos llaman a esto resistencia al cambio, pero en realidad es una falta de comprensión de la propuesta de valor central.

¿Qué características tiene esta categoría?

• El equipo no entiende qué es DevOps y cómo puede mejorar el estado actual del proyecto, equipo u organización.
• Problemas excesivos de soporte / reportes negativos de calidad (QA).
• Se presentan "extinciones de incendios" constantes, causando pobre equilibrio entre la vida laboral y personal.
• No se suele utilizar un sistema de control de versiones de código o se utiliza de una manera ineficiente.
• Los integrantes del equipo, con frecuencia, se quejan de los despliegues dolorosos.

¿Qué se debe hacer?

• Empezar a reconocer los beneficios de implementar DevOps:

• Empezar a experimentar con herramientas de CI/CD y adoptar un sistema eficiente de control de versiones de código.

3. Primeros pasos

Esta categoría es para equipos que recién comienzan a probar conceptos de DevOps y aún son inmaduros en su implementación. Aquí se encuentra el equipo hipotético que "hace DevOps" instalando un servidor Jenkins para automatizar tareas sencillas.

Eso no significa que sean organizaciones de ingeniería inmaduras. En cambio, sus procesos suelen ser estáticos y familiares, pero podrían no estar sirviendo bien a la organización. Los equipos a este nivel experimentan regularmente proyectos que van más allá del tiempo y el presupuesto.

¿Qué características tiene esta categoría?

• El equipo u organización entiende los beneficios que traería DevOps a su trabajo y está dispuesto a empezar a realizar cambios.
• La automatización se limita a algunos experimentos o pruebas de concepto con herramientas de CI/CD o análisis de código.
• El equipo de operaciones se ve como un equipo separado de los demás.
• Raramente incluyen metodologías DevOps durante las etapas de planificación o implementación temprana del proyecto/Sprint.
• Operaciones suele recibir nuevo código de los desarrolladores o QA con poco conocimiento de cómo funciona o cómo implementarlo.
• A menudo se presentan dificultades para tratar de encajar nuevo código al resto del sistema lo que resulta en un proceso de integración muy manual.
• No se da mucha importancia al unit testing.
• Los test de QA se hacen de manera manual.
• El equipo entiende y aplica prácticas "aceptables" para el versionamiento de código.

¿Qué se debe hacer?

Un equipo a este nivel debe observar cada faceta de madurez de DevOps y buscar mejorar gradualmente. El mejor lugar para comenzar es reconocer las fortalezas y debilidades del equipo en lo que respecta a la mejora continua.

Al adoptar una actitud más centrada y un proceso estructurado para la mejora continua, los equipos reconocerán que pueden mejorar cada una de las otras facetas de forma incremental e independiente.

Las operaciones pueden comenzar a adoptar y estandarizar la configuración de servicios y recursos a través de herramientas de administración de configuración.

Los equipos de ingeniería pueden comenzar a agregar pruebas automatizadas para validar la calidad de cada compilación de software.

4. Automatización y comunicación

Un equipo en esta categoría se ha comprometido en gran medida con una implementación DevOps, pero es posible que todavía no vea los rendimientos prometidos. Ciertamente, la sensación es que algunos cambios han mejorado las cosas para el equipo, pero algunos sienten que se realiza mucho trabajo y notan poco beneficio.

Se percibe una incompetencia consciente que generalmente está presente en los primeros 12 meses de una implementación DevOps. Todo esto puede sonar como pesimismo, pero se tiene que comenzar en alguna parte. Se produce mucho aprendizaje en esta etapa.

Tanto “Dev” como “Ops” se familiarizan con las herramientas y comienzan a comprender mejor las necesidades de los demás. Algunos procesos se mejoran, pero generalmente esas mejoras son departamentales y no de todo el sistema.

¿Qué características tiene esta categoría?

• Operaciones y desarrollo conversan regularmente sobre los próximos despliegues y correcciones de errores.
• Las nuevas implementaciones no toman por sorpresa al equipo de operaciones y/o desarrollo.
• Operaciones planifica qué cambios de configuración necesitará el nuevo código e implementan dichos cambios mientras los ingenieros desarrollan la función.
• El equipo puede sentir, al menos de manera parcial, los beneficios de la automatización.
• Se lleva a cabo unit testing como parte fundamental del desarrollo.
• Se llevan a cabo análisis estáticos o de seguridad automatizados.
• Los ambientes y soluciones cuentan con pipelines de CI/CD.
• Se implementan métricas y/o alarmas automatizadas.
• El control de código y versiones es eficiente. Además está debidamente estandarizado e implementado.
• Los analistas de QA han empezado a experimentar con pruebas automatizadas.
• Los encargados de operaciones participan de las ceremonias ágiles.
• Operaciones ha automatizado y regulado, parcialmente, la creación de recursos e infraestructura mediante la metodología IaC (Infrastructure as code).

¿Qué se debe hacer?

Uno de los mayores enemigos a este nivel es la complacencia. Muchos equipos alcanzarán este nivel después de meses o años de progreso y simplemente se estancaran. Han creado un proceso que "funciona para ellos" y carecen de personas con la visión o la autoridad para impulsarlos a pasos más avanzados.

Al igual que las correcciones en la categoría anterior, la mejor forma de avanzar en esta categoría es a través de una mejora incremental constante.

Ahora que han comenzado a recopilar métricas sobre su equipo y el rendimiento del software, los equipos deben evaluar críticamente estos datos para darse cuenta que funciona bien y que debe ser mejorado.

5. Colaboración y Organización

La mejora continua es una pieza importante de la compañía y los colaboradores de cada parte de la organización identifican regularmente nuevas áreas de mejora.

Esta categoría se define como una etapa de competencia consciente que generalmente existe entre los primeros dos a cuatro años.

En esta etapa, la organización comprende que DevOps no es sólo ingeniería y scripts automatizados, si no que se trata de mejorar todo el ciclo de vida de desarrollo de software (SDLC), desde el inicio de la idea de negocio hasta la ejecución en producción.

¿Qué características tiene esta categoría?

• El equipo mide constantemente cómo sus cambios impactan el resultado final del negocio.
• Se generan métricas sobresalientes que permiten cuantificar el impacto que las nuevas versiones y/o funcionalidades tienen en el rendimiento general del software.
• Cada equipo puede señalar de forma confiable qué función introdujo errores individuales.
• El equipo da cumplimiento con las revisiones de código para que se puedan identificar errores de manera temprana.
• El sistema de CI/CD funciona perfectamente más del 90% del tiempo.
• Un amplio conjunto de pruebas automatizadas de alta calidad acorta drásticamente la ventana de control de calidad.
• Las pruebas automatizadas y/o de QA están implementadas dentro del sistema de CI/CD.
• Se implementan altos parámetros de aceptación para la aprobación de nuevos despliegues.
• Operaciones ha adoptado el agilismo en su método de trabajo.
• Operaciones a automatizado y regulado totalmente la creación de recursos e infraestructura mediante la metodología IaC (Infrastructure as code).

¿Qué se debe hacer?

Una vez más, el proceso para superar esta categoría es una mejora continua e incremental. El siguiente paso para los equipos de proyecto más allá de este punto es comenzar a unir los datos del equipo de operaciones y desarrollo directamente a las conversaciones con los clientes. De esta manera, pueden identificar el producto mínimo viable para cada característica.

Idealmente, los equipos en este nivel comienzan a involucrar a los equipos de cumplimiento directamente en el proceso de planificación. El código inseguro y no conforme nunca llega al software. El equipo de operaciones continúa trabajando para automatizar completamente su línea de integración continua, solucionando cualquier necesidad de intervención manual.

En resumen, los cambios a este nivel son de refinamiento y no técnicos.

Con la mente en DevSecOps

DevOps no solo concierne a los equipos de desarrollo y operaciones, sino también al negocio y a la organización. La seguridad TI también debe desempeñar un papel integrado en el ciclo de vida completo de sus aplicaciones.

DevSecOps implica pensar desde el principio en la seguridad de las aplicaciones y de la infraestructura. También implica automatizar algunas puertas de seguridad para impedir que se ralentice el flujo de trabajo de DevOps.

Etapa DevSecOps

¿Qué características tiene esta categoría?

• El equipo de ingeniería puede decir con precisión cuántos errores se están introduciendo y qué impacto tiene el nuevo código en cualquier ambiente.
• Los datos y métricas generados están directamente vinculados a los niveles de satisfacción del cliente.
• La organización y/o cliente tiene una amplia aportación en cada decisión tomada por los equipos técnicos.
• Los análisis de seguridad son parte fundamental del ciclo de desarrollo.
• Todos los miembros del equipo y de la organización/cliente entienden con claridad (en mayor o menor medida) los "procesos DevOps" que se llevan a cabo.
• Todos los procesos están debidamente estandarizados y documentados.

¿Qué se debe hacer?

La madurez es entender que no puedes hacerlo todo de una vez y que siempre hay espacio para la mejora. Los equipos maduros se acercan a moverse a través de estos niveles como un proceso.

Una vez más, el corazón de DevSecOps es mejorar continuamente el rendimiento de un equipo de varias maneras. En lugar de intentar dar un paso gigante, los equipos maduros toman muchos pequeños.

“La perfección se alcanza, no cuando no hay nada más que añadir, sino cuando ya no queda nada más que quitar.” Antoine de Saint-Exupéry.

Conclusiones

Para dar cierre a esta categorización, sólo resta recalcar en que no existe una receta mágica para DevOps ni mucho menos una que funcione cada vez y para todos por igual.

Dada la gran cantidad de herramientas y plataformas tecnológicas que existen en la actualidad, que nos permiten llevar a cabo las tareas y los procesos que DevOps comprende, se debe realizar un buen proceso de elección de herramientas, ya que no todas ellas se acomodan a los recursos y necesidades que presenta el equipo u organización.

Además se puede dar el caso de que cierta práctica o estándar no se acomode a nosotros y se deba buscar una alternativa igual de efectiva. Y más importante aún, es que no se debe ser reacios al cambio.

En el mundo TI se está evolucionando constantemente y siempre debemos estar preparados y dispuestos a cambiar nuestra forma de trabajar.