DevOps
Una cultura y un conjunto de prácticas de automatización que fusionan el desarrollo y las operaciones para que el mismo equipo construya, entregue y opere el software, con retroalimentación rápida desde producción de vuelta al código.
DevOps surgió como reacción a una disfunción concreta: los desarrolladores lanzaban el código por encima de un muro a un equipo de operaciones separado, a operaciones se le culpaba cuando se rompía, y el ciclo de retroalimentación entre escribir software y operarlo estaba roto. DevOps cierra ese ciclo. El equipo que construye el software también lo entrega y lo opera, y el dolor de operar algo fluye directamente de vuelta a las personas que pueden arreglarlo.
En la práctica, esa cultura se habilita mediante automatización: CI/CD para que los cambios fluyan a producción de forma segura y frecuente, disciplina de continuous delivery para que cada build sea enviable, infraestructura como código para que los entornos sean reproducibles en lugar de copos de nieve hechos a mano, y observabilidad (logs, métricas, trazas, alertas) para que el equipo vea qué hace realmente producción. Ninguna de estas herramientas es DevOps por sí sola. Son lo que hace que la cultura sea sostenible.
El título de «ingeniero DevOps» es en gran medida un nombre equivocado, y revelador. DevOps no es un rol que contratas para sentarse entre desarrollo y operaciones, eso solo reconstruye el muro con un nombre nuevo. Lo que la mayoría de las ofertas de «ingeniero DevOps» quieren en realidad es un ingeniero de plataforma o infraestructura que construye la automatización que usan otros desarrolladores. Persona útil, etiqueta equivocada. Si tu organización tiene un equipo DevOps que se encarga de los despliegues para que los desarrolladores no tengan que hacerlo, tienes operaciones con un cambio de marca, no DevOps.
Ejemplo de «tú lo construyes, tú lo operas» funcionando como debe: un ingeniero lanza un cambio el jueves, recibe una alerta a las 2 de la madrugada del viernes cuando provoca una fuga de memoria lenta, y pasa la madrugada arreglando su propio código. Eso es desagradable una vez. También es el sistema de revisión de código más eficaz jamás inventado, porque ese ingeniero nunca volverá a lanzar esa clase de bug, y la próxima vez que diseñe algo pensará en cómo se comporta a las 2 de la madrugada. Cuando un equipo de operaciones separado absorbe ese dolor en su lugar, la persona que podría prevenir la siguiente fuga nunca siente la consecuencia de la última, y los mismos errores se repiten indefinidamente. La alerta no es un castigo; es el bucle de retroalimentación.
La visión de Wavect: DevOps es una forma de trabajar, no un departamento. Construimos la automatización que permite a un equipo pequeño responsabilizarse de su software de principio a fin, y tratamos «tú lo construyes, tú lo operas» como el valor por defecto. Mira nuestro trabajo de desarrollo full-stack para ver cómo se traduce esto en la práctica.