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