De Agilidad y otras hierbas

Me estaba echando mayonesa sin mirar en una marraqueta (error de novato), cuando noté que no era mayonesa… ¡era pasta de ajo! Mientras me limpiaba la lengua con un pedazo de servilleta, pensé: “esto pasa cuando la ejecución no conversa con el diseño”… ¡igualito que en los proyectos sin arquitectura clara ni DevOps! 😆 Les cuento: se han fijado que muchas veces la arquitectura de soluciones se diseña en una torre de cristal, llena de diagramas bonitos y flechitas de colores, mientras DevOps está en las trincheras apagando incendios con un balde chico. Esa separación es como tener un plano de casa sin considerar dónde van los enchufes. 🏡⚡ Cuando arquitectura y DevOps trabajan juntos, la magia ocurre. ¿Por qué? Porque el arquitecto define el qué y el por qué , y DevOps define el cómo y el cuándo ... y si se alinean, evitamos desastres como ese deploy del viernes a las 5pm que rompió todo y dejó al equipo comiendo completos fríos. 🌭🔥 🔁 Cosas buenas que pasan cuando se entienden: ...

Estaba limpiando unos audífonos que sobrevivieron toda la pandemia, y entre pelusas y nostalgia, me acordé de esos días en que el mundo se caía a pedazos… pero nuestros pipelines seguían funcionando como si nada. 😅 Les cuento una cosa: en mi servicio, DevOps no fue solo una mejora técnica durante la pandemia… fue una tabla de salvación con flotadores incluidos. Cuando todo se volvió remoto, incierto, y con más reuniones por Teams que neuronas despiertas, el hecho de tener un flujo de trabajo automatizado y confiable nos mantuvo en pie. 🚤📦 Se han fijado que DevOps es como ese amigo ordenado que uno no valora hasta que todo se va al carajo. Deploys automatizados, revisiones por pull request, tests en la nube, alertas… todo fluyó. Mientras medio equipo hacía home office en pijama con niños gritando de fondo, nuestros cambios en producción seguían igual de controlados que cuando íbamos a la oficina con camisa y cara de lunes. 🧃🩳 El despliegue de bases de datos, los procedimientos a...

Estaba abriendo una lata de porotos con vienesas mientras pensaba en esos despliegues de base de datos durante la pandemia… esos tiempos en que el caos era global, pero nosotros igual metíamos ALTER TABLE con fe y un café cargado. ☕😅 Les cuento: en mi servicio también usamos DevOps para los despliegues de base de datos desde hace rato. No era la panacea, pero ¡ayudó caleta! Cuando estábamos todos en pantuflas y con Zoom en la cocina, tener un pipeline que tirara los INSERT , UPDATE , funciones y procedimientos almacenados, todo validado por el DBA como un sensei con su katana, fue un salvavidas. 🧙‍♂️💾 Pero ahora queremos ir más allá. Porque sí, tener control de cambios y automatización es bacán, pero igual sigue oliendo a “artesanal”: scripts sueltos, miedo al DROP , y planillas Excel con los pasos del despliegue pegadas con cinta. 🎭📋 La pregunta que ronda es: ¿cómo llevamos eso al siguiente nivel? 💡 Algunas ideas locas (pero no tanto): ➜ Versionamiento de esquemas : herram...

Me estaba rascando la cabeza frente al microondas porque apreté "papas" en vez de "pizza", y terminé con una roca radiactiva en vez de cena. En ese momento pensé: “¿Y si tuviera un script que evitara mis decisiones idiotas?”... ¡Exactamente como IaC y GitOps en producción! 😅 Les cuento: Infrastructure as Code (IaC) y GitOps son como Batman y Robin, pero sin los traumas emocionales —o quizás con los mismos, pero en YAML. IaC es escribir tu infraestructura como si fuera un poema técnico: declaras recursos, redes, permisos… todo con código, todo versionado, todo lindo. 📜 Ahora, GitOps llega y dice: “ya que escribiste la infraestructura como código… ¿por qué no la desplegamos también desde Git, con flujos automatizados, revisiones en pull requests, y monitoreo constante?”. Es como que IaC cocina el plato y GitOps lo sirve en la mesa sin derramar la salsa. 🍝👌 Se han fijado que cuando uno combina estas dos cosas, el caos baja un 83% (dato no verificado, pero suena ...

Estaba intentando hacer pan amasado, con la receta pegada en el refrigerador con un imán de Batman, cuando pensé: "¿Y si pudiera hacer rollback de esta masa que quedó como ladrillo?" 🤦‍♂️ Ahí me cayó la teja: ¡eso es lo que hace GitOps pero con infraestructura! Se han fijado cómo antes todo era configurar servidores a mano, cual chef improvisando con lo que hay en la despensa. Después vinieron los scripts, los pipelines, y ahora… GitOps. Es como decir: “¿sabís qué? Que el código se encargue de todo, y si algo falla, me devuelvo al commit anterior y voilà ”. 🧑‍💻✨ GitOps es llevar el principio de todo como código hasta las últimas consecuencias. La infraestructura vive en Git, se gestiona con PRs, y si alguien mete la pata, no se grita ni se reza: se hace revert y sanseacabó. 🔁😇 Y lo mejor es que no solo da control, también da paz mental. Porque saber que tu clúster se va a auto-reparar solo si alguien lo rompe, es como tener un robot que te arregla la cama y además t...

Me estaba preparando un café bien cargado —de esos que parecen alquitrán pero te devuelven el alma— cuando abrí el dashboard de costos de la nube y casi escupo el primer sorbo encima del teclado. ¡La factura parecía el PIB de un país pequeño! 😱 Les cuento una cosa: ajustarse el cinturón en FinOps no es como dejar de comprar cerveza artesanal para pasar al schop de litro del supermercado... es más como revisar si realmente necesitas prender todas las luces de la casa solo para encontrar las llaves. 💡 Se han fijado que en muchas empresas todos hablan de optimizar costos en la nube como si fuera apagar un par de instancias y listo. Pero la verdad es que esto es casi una filosofía de vida: mezclar finanzas con operaciones y algo de espiritualidad, porque necesitas fe para entender algunas facturas de AWS. 🔮 El punto es que no se trata de cortar por cortar. Es preguntar: ¿esto que estoy pagando genera valor? ¿Estamos usando las cosas que contratamos o solo las dejamos encendidas ...

Me estaba tomando una cerveza mientras trataba de acordarme de una contraseña que juraba haber guardado en un post-it... pero el post-it había desaparecido misteriosamente. Ahí, entre sorbo y sorbo, me vino la iluminación: ¡la gestión de secretos en DevOps, po hombre! 😅 Se han fijado que en los equipos de DevOps, la paranoia es parte del desayuno. Porque claro, uno puede automatizar despliegues, pipelines, servidores mágicos que se autoconfiguran... pero si metís las credenciales en el código, ¡te van a funar más rápido que un tuit de hace 10 años! 💣📉 La gestión de secretos es básicamente esconder tus contraseñas, tokens, claves API y otros encantos oscuros lejos de miradas curiosas (y de tus propios desarrolladores flojos, que les gusta copiar y pegar). Para esto usamos herramientas como Vault , AWS Secrets Manager , o GitHub Actions Secrets , que son como el horóscopo de la seguridad: no sabés si te están ayudando o solo dándote calma, pero al menos dormís mejor 😌🔒. Les cuen...

Estaba divagando mientras miraba una mancha de café en mi polera —que curiosamente parecía un mapache haciendo yoga— y me acordé de esas entrevistas de trabajo medio esotéricas donde te muestran manchas tipo Rorschach, y uno tiene que decir lo primero que se le viene a la mente... ¡como si adivinarle al psicólogo fuera parte del contrato! 😅 Les cuento una cosa: hay entrevistas donde el ambiente se transforma en una mezcla entre sesión de tarot y terapia breve. Te muestran una mancha y te preguntan: “¿Qué ves aquí?” Y uno, que solo quiere el trabajo, se siente tentado a decir cualquier cosa aceptable: “Un cisne volando hacia sus metas” , o “un equipo colaborativo en plena sinergia” . Pero por dentro uno piensa: “es un perro derritiéndose sobre un teclado, como yo después de una reunión de dos horas sin café” 🐕💻☕ La verdad es que estas pruebas proyectivas, más que decir si eres un genio o un sociópata funcional, miden cómo te enfrentas a lo ambiguo , cómo elaboras ideas con poco c...

Estaba echándome una siesta camuflada como "revisión de logs" —una técnica milenaria del ingeniero cansado— cuando me cayó la pregunta como una gota de café frío en la frente: ¿dónde empieza y dónde termina la Infraestructura como Código (IaC)? 🎯 Les cuento una cosa. Se han fijado que cuando uno habla de IaC, algunos creen que con tener un archivo main.tf ya están listos para la revolución digital. Y no, compadres. Eso es como decir que porque me compré zapatillas deportivas, ya estoy listo para correr una maratón 🏃‍♂️😅. ¿Dónde empieza? Empieza en el deseo de no repetir manualidades ridículas . Cuando dices: “no quiero volver a configurar a mano un servidor en mi vida”, ahí nació tu IaC. Parte con una mentalidad: automatizar todo lo que puedas para que tu infraestructura sea reproducible, versionable y testeable . Archivos YAML, HCL, scripts en Bash, lo que sea que te permita definir tu infraestructura como si fuera un software. ✔️ ¿Dónde termina? Ah, ahí está el chi...

Me estaba preparando un café con la ilusión de que este lunes fuera distinto, cuando abrí el correo y ¡bam! Una oferta laboral que parecía escrita por el mismísimo Leonardo da Vinci versión programador: "Buscamos a alguien que se sepa de memoria todas las instrucciones de C++, Python, Java, JavaScript, y si puede también algo de COBOL, por si acaso. Que no use Google. Que respire código. Que tenga espíritu de compilador." 😅 Se han fijado que a veces los reclutadores creen que los programadores somos como esos libros de bolsillo de los 90: "Todo HTML en 21 días", pero versión viviente. Como si uno tuviera un disco duro en la cabeza y pudiera recitar de memoria cómo se usa std::transform o las 42 formas de hacer un for en JavaScript sin pestañear 🦾. Y claro, uno les dice que usa documentación, que Stack Overflow es como mi segunda casa (a veces más que la primera), y te miran como si estuvieras confesando que copiaste en la PSU. Pero seamos honestos, hasta los ...

Me estaba haciendo un pan con mantequilla —pero como buen despistado, agarré margarina light sin darme cuenta y me quedé mirando la etiqueta como si me hubieran estafado— cuando me cayó la gran verdad: “Oye, en DevOps muchos creen que el deploy es el final del camino… ¡pero es recién el comienzo del verdadero cahuín!” . Les cuento una cosa: se han fijado que hay gente que piensa que DevOps es solo automatizar el deploy. Como si llegar a producción fuera la meta final, el check en la lista, la copa del mundo. Pero no po, el verdadero trabajo empieza CUANDO el sistema está corriendo y empieza a enfrentarse al mundo real, con usuarios reales, errores reales… y estrés real . 🔥 Así que, ¿qué hay más allá del deploy? ✔️ Monitoreo y observabilidad Tu aplicación no solo “vive”, respira, suda, sufre y a veces se ahoga . Tienes que monitorear: – Latencia, throughput, errores. – Logs estructurados y accesibles. – Tracing distribuido si tienes microservicios. No basta con mirar el dashboa...

Me estaba preparando un café —con la cucharita chica porque no encontraba la grande, y terminé echándole cinco cucharadas sin querer— cuando me vino la revelación: “Oye, ¿y si aplicáramos DevOps en cosas que no sean TI? ¿Pa’ qué más sirve esta filosofía loca de automatizar, colaborar y mejorar?” Y ahí, con el café más fuerte que batería de reggaetón, se me ocurrieron estas 3 ideas medio locas pero posibles . Les cuento una cosa: se han fijado que DevOps, al final, no es solo tecnología: es una forma de trabajar . Es colaboración, automatización, mejora continua, feedback rápido. Y eso se puede aplicar en cualquier área donde haya procesos repetitivos y necesidad de coordinar gente y resultados . 🔥 Así que aquí van mis 3 propuestas disparatadas (pero con cariño): 1. DevOps en la cocina de un restaurante Imagínate un restaurante donde el “pipeline” es el proceso desde que piden la orden hasta que el plato llega a la mesa: ✔️ Automatización de pedidos y control de stock (CI: integ...

Me estaba sirviendo una cerveza —porque me la merecía después de pelear con un merge conflict eterno— cuando me pregunté: “¿Y cuándo fue la última vez que alguien auditó este repo? ¿O estamos navegando en un basural elegante?” Y ahí mismo, mientras caía la espumita, me di cuenta: la auditoría de repositorios es como ir al médico… nadie quiere, pero si no vas, después es peor . Les cuento una cosa: se han fijado que los repos envejecen como la leche, no como el vino , si nadie los revisa. Archivos olvidados, ramas que nadie usa, secretos expuestos, dependencias obsoletas… todo eso se acumula hasta que explota en el peor momento . Por eso la auditoría no es solo para empresas grandes: cualquier repo que viva más de un mes ya necesita una miradita crítica . 🔥 ¿Cuándo hacer una auditoría de repos? ✔️ Antes de un release importante o migración : para asegurar que solo subes lo necesario y nada comprometedor. ✔️ Cada cierto tiempo (trimestral, semestral) , como limpieza de primavera di...

Me estaba calentando unas sopaipillas (porque obvio, llovía) y justo mientras les echaba pebre pensé: “Oye, ¿y si alguien sube al repo todo lo que no debe? ¿Qué tan rápido se prende fuego la oficina?” Y ahí, entre mordisco y estornudo por el ají, decidí escribir la lista negra de archivos que JAMÁS deberían terminar en tu repo . Les cuento una cosa: se han fijado que hay gente que sube TODO. Como si el repo fuera su escritorio personal. Pero Git no es tu Dropbox, ni tu pendrive. El repo es solo para el código fuente y lo esencial para construir, no para basura local, secretos ni resultados . Así que aquí va mi 📝 lista de “prohibidos pero clásicos” : ✔️ Credenciales y claves secretas – .env con tokens de API, passwords de BD, claves privadas SSH. – Archivos config.yml o settings.json con accesos. 🔥 Esto es lo PRIMERO que buscan los bots cuando escanean GitHub… no les des el gusto. ✔️ Carpetas de dependencias instaladas – node_modules , vendor/ , Pods/ (de CocoaPods), pack...

Estaba divagando mientras intentaba encontrar mi destapador (spoiler: estaba en el cajón de los calcetines, no pregunten) y me vino el rayo de lucidez: “Oye, el .gitignore es como ese amigo que siempre te avisa antes de que metas la pata… pero nadie lo pesca al principio” . Así que me serví la chela, y aquí va mi reflexión sobre la importancia vital de ese archivo tan ninguneado . Les cuento una cosa: se han fijado que los repos, si los dejas solos, empiezan a llenarse de mugre. Que si node_modules , que si __pycache__ , que si .class , que si .DS_Store (¡maldito archivo eterno de Mac!). Si no tienes un .gitignore bien configurado, todo eso termina subido al repo, ocupando espacio, confundiendo commits y arruinando fusiones . 🔥 ¿Por qué es tan importante? ✔️ Evita subir archivos generados automáticamente : esos que no necesitas versionar porque se regeneran (builds, binarios, logs…). ✔️ Evita exponer archivos sensibles : .env , configuraciones locales, credenciales… porque nadi...

Me estaba comiendo un completo (con palta, OBVIO) cuando me cayó encima la salsa… y pensé: “Esto es como los repos: si no limpias a tiempo, después cuesta el triple sacarlo” . Y ahí mismo, entre servilletas y culpa, me puse a reflexionar sobre la importancia de tener el repositorio limpio y ordenado, antes que se vuelva una trampa mortal para el siguiente incauto . Les cuento una cosa: se han fijado que los repositorios empiezan súper lindos, con su README.md , su .gitignore , todo en orden… y después, como por arte de magia, empiezan a aparecer carpetas misteriosas, archivos de prueba, backups con nombres como final2_OK_definitivo.zip , y commits tipo “arreglando cosas” . Si no paras esa espiral, terminas con un repo que parece la pieza del primo acumulador . 🔥 ¿Por qué es importante limpiar? Porque un repo sucio: ✔️ Es difícil de entender. ✔️ Hace más complejas las fusiones y pull requests. ✔️ Aumenta el tamaño sin necesidad. ✔️ Esconde basura que puede incluso subirse a prod...

Me estaba preparando un café —pero se me cayó el filtro y ahora tengo un mini pantano en la cocina— cuando me puse a pensar: “Oye, los tags en Git son como esas etiquetas en las poleras… uno no las pesca hasta que la ropa se pierde en la casa” . Y es que sí, los tags en desarrollo son invisibles… hasta que los necesitas desesperadamente . Les cuento una cosa: se han fijado que cuando el código está en plena vorágine de commits, merges y pushes, todo es una maraña de versiones . Pero llega el momento crítico: “¿qué versión exacta mandamos a producción?” … y ahí es donde los tags aparecen como el único punto de referencia confiable . ➜ ¿Qué son? Los tags son marcas fijas en la historia de tu repo , que señalan un commit específico como importante. Como poner una banderita que dice: “desde aquí salió la versión 1.0.0” . ✔️ No cambian aunque sigas haciendo commits. ✔️ No dependen de ramas volátiles. ✔️ Son como anclas en el tiempo. 🔥 ¿Por qué son tan importantes? Porque en DevOps,...

Estaba divagando mientras intentaba abrir una bolsa de papas fritas con los dientes (porque las manos estaban ocupadas sosteniendo una chela… prioridades, ¿cierto?) y me cayó la gran pregunta existencial: “Oye, ¿y qué cresta es realmente el artefacto en DevOps? ¿Por qué suena tan elegante si al final es solo… un archivo?” Así que aquí les cuento el misterio del artefacto . Les cuento una cosa: se han fijado que todos en DevOps hablan de “el artefacto” como si fuera el Santo Grial. Pero no es más que el paquete resultante de tu proceso de construcción (build) . Así como el chef termina su receta y pone el pastel en la bandeja, el artefacto es tu pastel empaquetado, listo para servirse . ➜ ¿Cómo nace? El artefacto nace en el pipeline de CI , después de que tu código: ✔️ se compila (si es Java, por ejemplo, queda como .jar o .war ), ✔️ se transpila (si es JS o TS, pasa a ser .js ), ✔️ se empaqueta (en Docker sería una imagen), ✔️ o simplemente se agrupa en un .zip o .tar.gz . ...

Me estaba calentando unas sopaipillas en el horno —porque llovía y uno se pone melancólico— cuando me acordé: “¡Chuta, si dejé la historia del código a medias! ¿Cómo voy a dejar al pobre ahí, a punto de llegar a producción?” Así que, con el olor a zapallo inundando la cocina, vengo a cerrar esta epopeya. Les cuento cómo termina esta odisea: PARTE 3: El glorioso (y temido) paso a producción Después de sobrevivir los ambientes de pruebas, staging, QA, revisiones manuales y validaciones místicas de los seniors del equipo, tu código finalmente está listo para saltar a producción . Aquí pasa algo mágico (y medio aterrador): ✔️ Se ejecuta el pipeline final. ✔️ Se actualizan los servidores, contenedores o lambdas. ✔️ A veces hay migraciones de base de datos (que todos rezamos que no rompan nada). ✔️ Se activan validaciones post-deploy: health checks, smoke tests, monitoreo inicial. En este punto, el código ya está “en vivo” , sirviendo a usuarios reales que no tienen idea del parto ...

Me estaba preparando un café —pero sin darme cuenta usé sal en vez de azúcar, clásico error multitarea— cuando me acordé: “¡Oye! ¡Les debo la segunda parte del viaje de nuestro código!” Y ahí, mientras tomaba ese café sospechosamente salado, me reí solo pensando: el camino de tu código a producción es igual… lleno de cosas que uno no planeó pero que igual pasan . Bueno, les cuento cómo sigue esta odisea: PARTE 2: El salto al staging Tras haber pasado el temido CI (integración continua), tu código ya está “bendecido” para avanzar. Ahora entra a la etapa CD (entrega continua o despliegue continuo) , que es como ese momento en que ya imprimiste el informe, pero ahora tienes que entregarlo al profe sin que se caiga en un charco. Aquí pasan varias cosas: ✔️ Empaquetado : tu código no viaja solo. Lo meten en un contenedor (Docker), o un artefacto (JAR, WAR, un zip… depende de tu stack). Es como meter al código en su mochila con lonchera y todo. ✔️ Despliegue en ambientes previos : an...

Me estaba tomando una cerveza mientras peleaba con un merge conflict (otra vez… siempre pasa los lunes, no sé por qué) y me puse a pensar: “¿Qué pasa realmente con este pobre código desde que le doy commit hasta que aparece en producción? ¿Qué odisea vive?” Así que les voy a contar la travesía de nuestro querido código, en 3 actos, como si fuera una película de bajo presupuesto pero con harto corazón . PARTE 1: El nacimiento y el push Todo empieza contigo, programador, tipeando frenéticamente mientras suena música épica de fondo. Finalmente le das git add , git commit -m "arreglando cosas jeje" (porque sí, siempre va un “jeje” o un “fix” misterioso), y luego git push . En ese momento, tu código deja tu computador y sube a ese servidor remoto —GitHub, GitLab, Bitbucket, lo que uses— como quien mete la carta en el buzón . Ahí queda esperando que alguien (o algo) lo lea. Pero no todo es felicidad… porque el push no es el final, es el inicio de la inspección minuciosa : se ...