Glosario de Deploy de Agentes y DevOps

Los términos que aparecen una y otra vez en el Curso de Deploy de Agentes y en cualquier conversación sobre llevar un agente de tu máquina a producción: control de versiones, pipelines, contenedores, nube y observabilidad. Como todo glosario de la academia, crece con cada bloque nuevo del curso.

Git y control de versiones

Git — el sistema de control de versiones estándar: guarda la historia completa de tu código y permite trabajar en paralelo sin pisarse. Toda la práctica de deploy moderno arranca acá.

Repositorio (repo) — el proyecto versionado con Git: los archivos más toda su historia de cambios. Vive local en tu máquina y remoto en GitHub.

Commit — una fotografía guardada del proyecto en un momento dado, con un mensaje que explica el cambio. La unidad mínima de la historia; deshacer algo es volver a un commit anterior.

Branch (rama) — una línea de trabajo paralela que sale del código principal. Te deja desarrollar una feature sin tocar main hasta que esté lista.

Merge — juntar los cambios de una rama en otra. Es cómo tu feature terminada entra al código principal.

Conflicto de merge — cuando dos ramas tocaron las mismas líneas y Git no sabe cuál dejar; te pide resolverlo a mano. Menos frecuente si integras seguido y en cambios chicos.

.gitignore — el archivo donde declaras qué no versionar: dependencias, builds, y sobre todo secretos y archivos .env. Lo primero que se configura en un repo serio.

Stash — guardar cambios a medio hacer en un cajón temporal para cambiar de rama sin perderlos ni commitearlos. Los recuperas después con git stash pop.

Revert — deshacer un commit creando uno nuevo que aplica el cambio inverso. Seguro para historia compartida porque no reescribe el pasado.

Reset — mover la rama a un commit anterior. Potente y peligroso: --hard bota cambios sin vuelta. Evítalo en ramas que otros usan.

Rebase — reescribir la historia de una rama para que parezca que salió del último main. Deja un historial lineal y limpio, pero nunca se hace sobre ramas ya compartidas.

Convenciones de equipo

Conventional Commits — una convención para escribir mensajes de commit con un prefijo fijo (feat:, fix:, etc.). Permite generar changelogs y versiones automáticamente, y hace la historia legible de un vistazo.

feat — prefijo de commit para una funcionalidad nueva. En semver, gatilla una subida de versión menor.

fix — prefijo para arreglar un bug. Gatilla una subida de versión de patch.

hotfix — un arreglo urgente que va directo a producción por fuera del flujo normal, porque algo está roto ahora. Después se integra de vuelta a las ramas de desarrollo.

chore — commit de mantenimiento que no cambia el comportamiento del producto: subir dependencias, mover archivos, ajustar configuración.

docs — commit que solo toca documentación. Sirve para separar cambios de prosa de cambios de código.

refactor — cambio interno que reordena o limpia el código sin alterar lo que hace de cara al usuario.

semver (versionado semántico) — el esquema MAYOR.MENOR.PATCH (ej. 2.4.1): patch para arreglos, menor para features compatibles, mayor para cambios que rompen. El contrato que le comunica a quien te consume qué esperar.

GitFlow — un flujo de ramas clásico con ramas largas de develop, release y feature. Ordenado pero pesado; hoy se prefiere algo más liviano para entregas frecuentes.

Trunk-based — la estrategia opuesta: ramas cortísimas que se integran a main (el “tronco”) varias veces al día. La base del deploy continuo moderno.

CODEOWNERS — un archivo que declara quién es dueño de cada parte del repo. GitHub pide automáticamente su revisión cuando esas rutas cambian en un PR.

Code review — la revisión del código de un PR por otra persona antes de mergear. Atrapa bugs, difunde conocimiento y mantiene el estándar del equipo.

12-factor — una metodología de doce principios para apps de nube (config en variables de entorno, procesos sin estado, logs a stdout, paridad entre entornos). La receta clásica de una app fácil de desplegar y escalar.

Entornos (dev / staging / prod) — las copias del sistema por etapa: desarrollo para probar, staging como ensayo idéntico a producción, y prod donde están los usuarios reales. Un cambio sube por esta escalera.

Secret manager — un servicio que guarda credenciales y API keys cifradas fuera del código (Secret Manager de Google, variables de Railway). El código las pide en tiempo de ejecución; nunca viven en el repo.

Testing

Unit test — una prueba automática que verifica una pieza chica del código de forma aislada. Rápidas y numerosas; son la primera red de seguridad de cualquier pipeline.

Mock — un reemplazo falso de una dependencia (una API, la llamada a un LLM) para que el test corra rápido, gratis y determinista, sin tocar el servicio real.

Fixture — datos o estado de partida preparados para un test, que se montan antes y se limpian después. Evitan repetir la misma preparación en cada prueba.

pytest — el framework de testing estándar de Python: descubre los tests, los corre y reporta. Base de casi todo pipeline de CI en proyectos Python.

Cobertura (coverage) — el porcentaje de líneas de código que tus tests efectivamente ejecutan. Útil como señal, engañoso como meta: 100% no garantiza que las pruebas sean buenas.

Golden dataset — un conjunto curado de casos con la respuesta esperada, que sirve de vara para evaluar un agente. Cuando el agente deja de acertarles, algo se rompió.

LLM-as-judge — usar un modelo para evaluar las respuestas de otro (o de tu agente) según una rúbrica. La forma práctica de medir calidad cuando no hay una respuesta “correcta” única.

Eval — una evaluación sistemática del comportamiento del agente sobre un set de casos. El equivalente a los tests, pero para lo probabilístico: mides calidad, no solo “pasa/falla”.

Regression gate — un umbral en el pipeline que bloquea el merge si la calidad del agente cae respecto de la versión anterior. Impide que una mejora en un lado empeore otro sin que nadie lo note.

CI/CD y GitHub

CI (integración continua) — la práctica de integrar y validar cada cambio de inmediato con tests y chequeos automáticos. Atrapa los problemas cuando son chicos y baratos de arreglar.

CD (entrega/despliegue continuo) — llevar automáticamente cada cambio validado hasta staging o producción. La continuación natural de CI: del commit al usuario sin pasos manuales.

Pipeline — la cadena automatizada de pasos que corre un cambio: instalar, testear, buildear, escanear, desplegar. Si un paso falla, se detiene.

GitHub Actions — el sistema de automatización integrado en GitHub para correr pipelines. Defines qué pasa ante cada push o PR con archivos YAML dentro del repo.

Workflow — un pipeline definido en un archivo YAML en .github/workflows/. Describe cuándo se dispara y qué jobs corre.

Job — un bloque del workflow que corre en su propia máquina limpia. Los jobs pueden correr en paralelo o encadenarse.

Step — cada paso dentro de un job: un comando o una acción reutilizable. Se ejecutan en orden.

Runner — la máquina que ejecuta un job, provista por GitHub o tuya (self-hosted). Arranca limpia en cada corrida.

Artifact — un archivo que un job produce y guarda para descargarlo o pasárselo a otro job: un build, un reporte de cobertura, una imagen. Vive más allá del runner que lo creó.

Status check — el resultado (verde o rojo) que un job reporta al PR. GitHub los muestra junto al botón de merge.

Required check — un status check que se declara obligatorio: sin él en verde, GitHub no deja mergear. La forma de hacer los tests innegociables.

Branch protection — reglas sobre una rama (típicamente main): exigir PR, checks verdes y revisiones antes de mergear, y bloquear el push directo. La barrera que protege producción.

Environment (de GitHub) — un entorno declarado en GitHub (staging, prod) con sus propios secretos y, si quieres, aprobación manual antes de desplegar. Une el pipeline con la puerta de despliegue.

Merge queue — una fila que integra y prueba los PRs de a uno contra el main más reciente antes de mergear. Evita que dos PRs verdes por separado rompan main al juntarse.

Seguridad y calidad (evaluación de brechas)

Dependabot — el bot de GitHub que vigila tus dependencias y abre PRs para actualizar las que tienen vulnerabilidades conocidas o quedaron viejas. Mantenimiento de seguridad en piloto automático.

CodeQL — el motor de análisis de GitHub que consulta tu código como si fuera una base de datos buscando patrones de vulnerabilidad. Corre en el pipeline y marca hallazgos en el PR.

Code scanning — la funcionalidad de GitHub que corre herramientas como CodeQL y muestra las alertas de seguridad junto al código. El tablero donde aterrizan esos hallazgos.

SAST (Static Application Security Testing) — análisis de seguridad que lee el código fuente sin ejecutarlo, buscando patrones peligrosos (inyección, secretos, malas prácticas). CodeQL es una herramienta SAST.

Secret scanning — la detección automática de credenciales filtradas en el repo (API keys, tokens). Si detecta uno, avisa y muchos proveedores lo revocan solo.

Quality gate — un umbral combinado de calidad (cobertura, bugs, deuda técnica, vulnerabilidades) que un cambio debe superar para avanzar. Si no lo pasa, el pipeline se frena.

SonarQube (SonarQube Server autohospedado / SonarQube Cloud en la nube, antes SonarCloud) — una plataforma que analiza el código y calcula su quality gate: bugs, code smells, cobertura y duplicación. Emite el veredicto verde/rojo que el pipeline respeta.

Snyk — una herramienta que escanea dependencias, contenedores e IaC en busca de vulnerabilidades conocidas y sugiere el arreglo. Complementa a Dependabot con más contexto.

Contenedores

Docker — la tecnología estándar para empaquetar tu app con todas sus dependencias en una unidad que corre igual en cualquier parte. Resuelve el clásico “en mi máquina funcionaba”.

Imagen — el paquete inmutable y de solo lectura con tu app, sus librerías y el sistema base. La plantilla desde la que se crean contenedores.

Dockerfile — la receta de texto para construir una imagen: de qué base partir, qué copiar, qué instalar y qué comando ejecutar. Se versiona junto al código.

Contenedor — una instancia en ejecución de una imagen: tu app corriendo, aislada del resto del sistema. Efímero por diseño; si muere, levantas otro idéntico.

Registry — el repositorio donde se guardan y distribuyen imágenes (Docker Hub, Artifact Registry). El pipeline sube la imagen acá y la nube la baja para desplegar.

Artifact Registry — el registry de imágenes y paquetes de Google Cloud. Donde suele aterrizar la imagen de tu agente antes de que Cloud Run la corra.

Infraestructura como código

Infraestructura como código (IaC) — describir tu infraestructura (servidores, bases de datos, permisos) en archivos versionados en vez de configurarla a mano por consola. Reproducible, revisable y con historia.

Terraform — la herramienta de IaC más usada: declaras el estado deseado de tu infra y ella lo crea, modifica o borra para que coincida. Funciona con casi cualquier nube.

HCL (HashiCorp Configuration Language) — el lenguaje declarativo en el que se escribe Terraform. Describes el qué (el resultado), no el cómo (los pasos).

Provider — el plugin de Terraform que sabe hablar con una plataforma concreta (Google Cloud, AWS, GitHub). Traduce tu HCL a llamadas de esa API.

Resource — cada pieza de infraestructura que Terraform gestiona: un servicio de Cloud Run, un bucket, un permiso. La unidad básica del HCL.

State (estado) — el archivo donde Terraform anota qué creó en el mundo real, para saber qué cambiar en la próxima corrida. La pieza más delicada: si se pierde o corrompe, Terraform se desorienta.

Backend remoto — guardar ese estado en un lugar compartido y con bloqueo (un bucket en la nube) en vez de tu disco. Imprescindible en equipo, para que dos personas no lo pisen a la vez.

Drift — cuando la infraestructura real cambia por fuera de Terraform (alguien tocó algo a mano) y deja de coincidir con el código. plan lo detecta y apply lo corrige.

Plan / apply — las dos fases de Terraform: plan te muestra qué va a cambiar sin tocar nada, apply lo ejecuta. Siempre revisas el plan antes de aplicar.

Nube y despliegue

Workload Identity Federation — el mecanismo para que GitHub Actions se autentique en Google Cloud sin una llave de servicio guardada como secreto. La nube confía en la identidad del pipeline directo; menos secretos que filtrar.

Cloud Run — el servicio serverless de contenedores de Google: le das una imagen y él la corre, escala y cobra por uso. El destino típico de un agente en este curso.

GKE (Google Kubernetes Engine) — el Kubernetes gestionado de Google, para cuando necesitas orquestar muchos contenedores con control fino. Más potente y más complejo que Cloud Run.

Serverless — el modelo donde no administras servidores: subes código o un contenedor y la plataforma se encarga de correrlo y escalarlo. Pagas por uso, incluido escalar a cero.

PaaS (Platform as a Service) — plataformas que se llevan casi toda la operación (Railway, Render): conectas el repo y ellas buildean y despliegan. Menos control, mucha menos fricción.

Railway — una PaaS simple y popular para desplegar apps y agentes conectando el repo. La opción de menor fricción para salir a producción rápido.

Rollout — el proceso de publicar una versión nueva reemplazando la anterior. Puede ser de golpe o gradual, según la estrategia.

Canary — desplegar la versión nueva a un porcentaje chico del tráfico primero, vigilar métricas, y recién ahí abrirla al resto. Limita el daño si algo salió mal.

Blue-green — mantener dos entornos idénticos (uno vivo, uno nuevo) y cambiar el tráfico completo de uno al otro. Si falla, vuelves al anterior al instante.

Feature flag — un interruptor que enciende o apaga una funcionalidad en producción sin desplegar de nuevo. Separa “publicar el código” de “activar la feature”.

Rollback — volver a la versión anterior cuando la nueva falla. Rápido y ensayado si tu despliegue está bien armado; ese es medio punto del curso.

Observabilidad y confiabilidad

Observabilidad — la capacidad de entender qué está pasando adentro de tu sistema en producción desde afuera, mirando sus señales. Sin ella, un agente en prod es una caja negra.

Logging estructurado — emitir logs como datos con campos (JSON) en vez de texto plano, para poder filtrarlos y buscarlos. La base para investigar un incidente sin leer líneas a ojo.

Tracing — seguir una petición a través de todos los pasos y servicios que atraviesa, con tiempos por tramo. En un agente, muestra cada llamada a herramienta y a modelo de un turno.

OpenTelemetry (OTel) — el estándar abierto para generar logs, métricas y trazas de forma uniforme. Instrumentas una vez y mandas los datos a la herramienta que quieras.

LangSmith — la plataforma de observabilidad de LangChain para agentes y LLMs: registra cada llamada, prompt y respuesta, y ayuda a depurar y evaluar. Muy usada en el ecosistema LangChain/LangGraph.

Langfuse — alternativa open source para observabilidad de LLMs: trazas, costos, evaluaciones y un panel de calidad. Se puede autohospedar.

p95 / p99 — el percentil 95 (o 99) de latencia: el 95% de las peticiones respondió más rápido que ese número. Describe la mala experiencia real mucho mejor que el promedio.

Rate limiting — limitar cuántas peticiones acepta tu servicio por usuario o por ventana de tiempo. Protege de abusos y de reventar tu presupuesto de tokens.

Prompt injection — el ataque donde una entrada (o un contenido que el agente lee) trae instrucciones ocultas para secuestrar su comportamiento. El primero de la lista OWASP Top 10 para aplicaciones LLM.

Guardrails — controles que filtran o validan lo que entra y sale del agente: bloquear temas prohibidos, datos sensibles o instrucciones maliciosas. La barrera entre el modelo y el mundo.

Retry / backoff — reintentar una llamada que falló, esperando cada vez un poco más (backoff). Absorbe errores transitorios de red o de la API sin caerse a la primera.

Timeout — el tope de espera por una respuesta antes de rendirse. Evita que una llamada colgada bloquee todo el sistema indefinidamente.

Circuit breaker — un cortacircuitos que, tras varias fallas seguidas de un servicio, deja de llamarlo un rato para no empeorar las cosas. Se reabre cuando el servicio se recupera.

Fallback — un plan B cuando la vía principal falla: un modelo más chico, una respuesta cacheada, un mensaje honesto de “no pude”. Degradar con gracia en vez de romperse.

Runbook — la guía paso a paso de qué hacer ante un incidente concreto (el agente responde lento, la API cae). Convierte el pánico de las 3 AM en una checklist.

SLO (Service Level Objective) — la meta medible de confiabilidad que te comprometes a cumplir (ej. “99.5% de peticiones bajo 2 s”). Define cuándo hay que actuar y cuánto riesgo puedes gastar.

Material relacionado

• Qué cambia en producción — el primer bloque del curso, donde arranca este vocabulario.
• Rollout y confiabilidad — canary, rollback, observabilidad y SLOs en acción.