Hay una leyenda urbana que circula…
Una joven desarrolladora se incorporaba a su primer gran trabajo nuevo. Era la primera vez que estaría en un equipo grande, con muchos compañeros, y ya no trabajaría sola y tendría que hacerlo todo por su cuenta. Era una de esas empresas antiguas. Ya sabes, los que estaban aquí antes de que la gente tuviera ordenadores en sus casas, que seguían siendo un gigante pero que no eran conocidos por su innovación ni por su voluntad de arriesgarlo todo con nuevas ideas. En su primer día, se encontró con un duro despertar: no había espacio para ella en la gigantesca y abarrotada oficina. No sólo no iba a trabajar estrechamente con su equipo, sino que fue enviada a trabajar al “anexo” en un edificio diferente, justo al lado de los administradores de sistemas.
Cuando se trata de desarrollo de aplicaciones Ya sea en la web o en el móvil, se trata de complejidades inimaginables. Los fundamentos básicos como escribir el código, probarlo, depurar y posteriormente desplegarlo están presentes todo el tiempo. Todas estas responsabilidades necesitan un equipo específico de expertos como los desarrolladores, ingenieros de control de calidad y los administradores del sistema para llevarlas a cabo. Así, es como una jerarquía de trabajo bien definida en la que cada equipo y sus miembros tienen algo diferente en lo que centrarse. Los desarrolladores se esfuerzan por añadir todas las funciones que pueden. Los equipos de control de calidad se esfuerzan por solucionar los fallos y hacer que las cosas funcionen. Los administradores de sistemas tienen sus propios problemas para mantener todo en funcionamiento sin problemas en todo momento. Todo parece ser sutil hasta que surge algún problema. Supongamos que surge un problema y se encuentra un error en el código. El ciclo de desarrollo, aparentemente fluido, se convertirá en un caos con preguntas como quién debe arreglar el trozo de código erróneo y cuándo se volverá a poner en marcha. Por lo general, si algo da problemas a los servidores de producción o al despliegue, los administradores son los primeros en responder.
Cuando entró y saludó, nadie respondió realmente. Algunos de ellos apartaron la vista de sus monitores y volvieron a lo que estaban haciendo. Incluso entre ellos, no hubo verdaderas conversaciones, sólo algunas preguntas a las que alguien respondía enseguida. — “ ¿QUIÉN desordenó mi configuración en el servidor DB?” — “I ARREGLADO tu configuración en el servidor de la base de datos, si es a lo que te refieres”. En el almuerzo, sus nuevos compañeros le dieron la bienvenida, pero también se burlaron de ella por su desafortunada posición: una joven desarrolladora rodeada por el enemigo. Compartieron historias sobre estos “administradores”, cómo siempre eran malhumorados, no les gustaba el equipo de desarrollo y cómo sentían que los servidores eran suyos para controlarlos y usarlos a su antojo.
Si el problema tiene que ver con el código, la tarea se transmite a los desarrolladores. Luego, estos ninjas de la codificación tienen que averiguar cómo arreglar las cosas y pasar el testigo al equipo de control de calidad para que lo prueben. Después de todo esto, la pieza de código probada se envía a los administradores del sistema para su despliegue. Por lo tanto, en un flujo de trabajo de este tipo, incluso un pequeño problema podría crear una cantidad sustancial de desorden. Además, a medida que aumenta el número de nuevas publicaciones (que es el caso actual), el asunto puede volverse desastroso.
Consideraban que el equipo de operaciones era el peor. Sólo les importa el tiempo de actividad y no les gusta la innovación. Es como si fueran más felices si todos ellos desaparecieran.
Con un problema que aún no se ha resuelto y un montón de características programadas para ser lanzadas, las cosas seguramente se saldrían de control. Este tipo de situaciones suelen provocar diferencias entre los equipos. Incluso podrían comenzar el juego de la culpa. Todo el mundo, desde los desarrolladores hasta los administradores de sistemas, pensaría que deben ser los otros los que empezaron todo el lío.
Pasó algún tiempo y se fue acostumbrando al trabajo. Estaba progresando, su equipo era estupendo e incluso se llevaba bien con la administradora que se sentaba a su lado. Por supuesto, no es que fueran amigos ni nada por el estilo, pero al menos ambos reconocían la presencia del otro. Incluso una vez, la llamó porque se había olvidado las llaves del coche y le ahorró tiempo. Formaba parte del equipo encargado de una de las aplicaciones más importantes que albergaba la empresa. La aplicación en sí no estaba mal, pero hacer cambios en ella llevaba una eternidad: aprobaciones tras aprobaciones, y nadie quería lidiar con los administradores. Solía ser una administradora cuando trabajaba sola. Tuvo que hacerlo todo. A diferencia de sus compañeras de equipo, entendía la importancia de la estabilidad. Aunque en realidad no formaba parte de los administradores, y la mayoría de ellos ni siquiera se fijaban en ella, a veces sentía que era su deber defenderlos cuando hablaba con sus colegas.
A nivel psicológico, un escenario así suele generar desconfianza como consecuencia de una prolongada falta de comunicación entre los equipos. Este conflicto de intereses convierte el simple ciclo de desarrollo de software en una pesadilla. Como resultado, las empresas pueden perder mucho dinero y tiempo valioso.
Tras un par de años allí, el promotor se sintió como en casa. Participó un poco en las bromas sobre los administradores, e incluso la invitaron a su torneo de bolos. Se había hecho amiga del chico que se sentaba a su lado, y a menudo se hacían favores mutuamente. No sabía que pronto iba a ocurrir algo que cambiaría la historia para siempre ( ? ). Habían pasado un par de semanas después de una importante actualización de la aplicación. Ella tuvo un papel importante en el impulso de esto, y “los poderes fácticos” quedaron muy satisfechos con su desempeño, así que decidieron asignarle un proyecto… un proyecto en solitario. Este complemento ayudaría a la aplicación principal y aprovecharía algunos de sus componentes. Por supuesto, había que convivir con él, pero, a diferencia de otros proyectos, el tiempo era esencial. Si querían que este proyecto tuviera éxito, tenía que ser rápido. Conocía la aplicación principal de principio a fin. Era la persona adecuada para el trabajo, pero había un gran problema: hacer cambios en el servidor que alojaba la aplicación principal sería súper lento. Sabía que el proceso de gestión del cambio la retrasaría y podría hacer fracasar este proyecto, pero también sabía que su amigo, el administrador, tenía toda la autorización necesaria para realizar los cambios que pudiera necesitar. Así que, si pudiera conseguirlo en el equipo, este proyecto podría tener una oportunidad. Por aquel entonces, las operaciones y el desarrollo eran entidades totalmente diferentes. Con su propio organigrama y su propia forma de hacer las cosas, conseguir que su amiga entrara en el equipo no iba a ser fácil.
En busca de una solución
Los inconvenientes de la cascada llevaron a las empresas a plantear cambios en su propia forma de gestionar las cosas. Esto evolucionó lentamente hasta convertirse en lo que conocemos como el Metodología ágil . Se cree que el término desarrollo de software ágil se acuñó en torno a 2001. Con Agile, los desarrolladores podrían lanzar proyectos mucho más rápido con un mejor trabajo en equipo y mejores habilidades interfuncionales. Incluso trabajando en entornos más exigentes y turbulentos, los equipos podían ahora responder mejor a los cambios. Una de las principales diferencias entre Agile y otros enfoques de software es que se centra en las personas que realizan el trabajo. Todo gira en torno a colaboraciones y prácticas constructivas en función de la situación.
La primera reacción fue la de su equipo. ¿Cómo es posible que prefiera trabajar con un administrador en lugar de con otro desarrollador? La segunda fue de su jefe: “¿Cómo podrías progresar con un administrador controlando cada uno de tus movimientos?” Y la tercera fue con el jefe del administrador: “¿Cómo podríamos permitirnos darte un administrador para un solo proyecto? Apenas podemos arreglárnoslas así”. La idea era inaudita, pero el proyecto contaba con un gran patrocinador de lo más alto de la cadena alimentaria. Después de explicar su idea, no tuvieron más remedio que ceder a sus exigencias. El último empujón fue uno que no esperaba. Era de su amiga, la administradora. Estaba enfadado con ella; su jefe le dijo que, además de esto, seguía apoyando todos los demás proyectos y que él era el responsable de proteger la infraestructura, cualquier asunto, y que su cabeza estaba en la tabla de cortar si algo salía mal.
Los equipos autoorganizados tienden a centrarse en las necesidades de los clientes, y hay mucho espacio para los cambios a lo largo del proceso. Sin embargo, todavía faltaba algo. La agilidad estaba bien, pero no podía calificarse de perfecta. A pesar de la estrecha colaboración, Agile seguía teniendo carencias en algunos frentes.
Ella le convenció, diciendo que le ayudaría y que sólo le molestaría cuando lo necesitara de verdad. Después de eso, el proyecto estaba en marcha. El desarrollo y las pruebas eran más bien lo habitual, pero cuando necesitaban subir los cambios al servidor de producción, necesitaban la ayuda del administrador. Estaba en llamas, entregando una característica tras otra. Con su ayuda, tanto los gestores como los clientes pudieron utilizar este software casi inmediatamente. Sólo había un problema, cada vez que tenían que pasar a producción, el administrador estaba involucrado, y estaba empezando a descuidar otros proyectos. No estaba contento.
La mayoría de las veces, los desarrolladores tenían que manejar la mayor parte de la presión, y los administradores de sistemas tenían poco espacio para contribuir. Además, los proyectos pueden descarrilarse fácilmente por falta de documentación adecuada y compromisos rigurosos. Por lo tanto, algo tenía que salvar todas estas brechas.
Al ver esto, se dedicó a un proyecto paralelo: empezó a escribir un guión que le ayudara a impulsar la producción más rápidamente. No era bonito, pero funcionaba, y rápidamente lo compartió con su amiga.
El inicio de DevOps
La historia de DevOps es sencillo pero revolucionario. El concepto de DevOps surgió de una discusión entre Andrew Clay y Patrick Debois en 2008. Les preocupaban los inconvenientes de Agile y querían idear algo mejor. La idea empezó a extenderse lentamente y, tras el evento DevOpsDays celebrado en Bélgica en 2009, se convirtió en una palabra de moda. Lo bueno de DevOps es que es más de lo que parece. No es sólo un intento de eficiencia; es un paso hacia el cambio cultural. Podemos llamarlo una mezcla de la filosofía ágil con el pensamiento lean.
Al principio se quedó un poco sorprendido. El guión tenía muy buena pinta y le gustaba automatizar cosas, pero nunca pensó en algunos de los elementos del guión. Por otro lado, era realmente rudimentario. No hay comprobaciones de ningún tipo en la infra, y asumió mucho. Pero al final, le encantó la idea, y le despejó el plato para trabajar en los otros proyectos. Así, pudo continuar con su trabajo sin interrupciones. Cada vez que el administrador tenía una oportunidad, trabajaba en el script para hacerlo mejor y más seguro para la infra. También trabajó en la apariencia del script, para que fuera sencillo de personalizar mediante botones, casillas de verificación, etc.
DevOps aúna los esfuerzos de todos los equipos que participan en el proyecto con una mayor integración. Esta integración interdepartamental entre desarrolladores, ingenieros de control de calidad y administradores de sistemas es más impresionante de lo que parece. Implementación de DevOps garantiza que los desarrolladores puedan participar en el despliegue, que los administradores puedan escribir scripts y que los ingenieros de control de calidad sepan cómo resolver otros problemas además de las pruebas. Además, los procesos pueden automatizarse y nadie tiene que esperar, ya que ahora pueden trabajar más estrechamente para desarrollar soluciones más rápidas y mejores. Una mejor comunicación y entendimiento también ayudaría a los equipos a reconocer las prioridades de cada uno. Y todas estas ventajas supondrían un aumento vertiginoso de la productividad y de la rapidez de las entregas.
Al cabo de un tiempo, tenían este empuje totalmente automatizado a la producción que era tan sencillo y personalizable, que incluso otros proyectos empezaron a utilizarlo. Con el tiempo, integró otras funciones, como la construcción de la aplicación o la notificación a determinadas personas sobre el progreso o los errores. Y así, amigos míos, es como nació una nueva raza de ingenieros informáticos.
Lo que hicieron sin darse cuenta fue convertirse en ingenieros DevOps: desarrolladores que entendieron la necesidad de los administradores (operadores) y administradores que entendieron la necesidad de los desarrolladores adoptando las habilidades de cada uno y creando un ciclo de desarrollo mejor y más rápido.