DevOps Basics · Linux Foundation Certified IT Associate

Fundamentos de DevOps

Resumen

DevOps es un enfoque sociotécnico para construir, desplegar y operar software con ciclos de retroalimentación cortos. Combina colaboración, responsabilidad compartida y aprendizaje sin culpa con integración continua, entrega continua, infraestructura como código y observabilidad. No es un producto ni un equipo llamado «DevOps» que sustituye a desarrollo y operaciones.

Esta guía es material de estudio independiente; no tiene afiliación ni aval de Linux Foundation.

Objetivos de aprendizaje

Definir DevOps y distinguirlo de una herramienta o un rol.
Diferenciar integración continua, entrega continua y despliegue continuo.
Relacionar automatización e infraestructura como código con la reproducibilidad.
Interpretar las métricas de DORA y los conceptos de SRE.
Reconocer prácticas como la paridad entre entornos.

Prerrequisitos y conexiones

No se exige experiencia previa. Conviene manejar la línea de comandos de Linux y comprender procesos, servicios y conexiones de red. El topic se conecta con git-concepts, que da trazabilidad a los cambios, y con containers, cuyas imágenes permiten promover un artefacto. También se relaciona con cloud-computing y security-basics.

Cultura, responsabilidad compartida y flujo de valor

DevOps parte de un conflicto habitual: desarrollo busca cambiar rápido y operaciones busca estabilidad. Cuando cada área optimiza su métrica aparecen entregas grandes, traspasos burocráticos e incidentes sin análisis profundo. DevOps optimiza el flujo completo de valor, desde la idea hasta el usuario.

Ese cambio implica responsabilidad compartida: quien construye participa en la operación y quien opera aporta durante el diseño. La colaboración se apoya en lotes pequeños y revisiones centradas en causas sistémicas. Un análisis sin culpa busca qué señales permitieron el fallo, no sancionar.

La automatización es un medio. Automatizar un proceso defectuoso solo produce errores más rápido. Antes conviene preguntar qué riesgo se reduce y cómo se comprobará la mejora.

Integración y entrega continuas

La integración continua (CI) integra cambios en una rama compartida con frecuencia y ejecuta construcción y pruebas automatizadas. Busca detectar incompatibilidades poco después de introducirlas. CI no significa desplegar en producción: cada cambio se compila y se valida contra el resto del código.

La entrega continua amplía la CI: cada cambio validado queda listo para desplegarse con un artefacto versionado y reproducible; la decisión puede ser manual. El despliegue continuo lleva automáticamente a producción todo cambio aprobado. No son sinónimos.

Una pipeline construye el artefacto, ejecuta pruebas unitarias y de integración, lo publica y lo despliega en un entorno de prueba. Luego se promueve el mismo artefacto a producción. No reconstruirlo reduce la diferencia entre lo probado y lo desplegado. Las banderas de funcionalidad separan el despliegue de la activación para usuarios.

Etapas de una pipeline

Una pipeline típica organiza el cambio en etapas que fallan pronto y aportan señal clara. La primera ejecuta comprobaciones estáticas: formato, reglas de estilo y análisis de código que no requieren ejecutar el programa. Sigue una etapa de pruebas unitarias sobre módulos aislados; al ser rápidas, conviene colocarlas antes de la construcción para detectar fallos evidentes sin consumir tiempo de compilación.

La construcción genera el artefacto: paquete, binario o imagen de contenedor. Después, las pruebas de integración verifican componentes que colaboran, como una API contra su base de datos de prueba. Las pruebas de extremo a extremo ejercitan flujos completos frente a un despliegue temporal; suelen ser las más lentas y las más sensibles a fallos ajenos al cambio, por lo que se reservan para pocos escenarios críticos.

Una etapa de seguridad puede escanear dependencias y artefactos en busca de vulnerabilidades conocidas, y otra puede comprobar que el paquete proviene del repositorio esperado. Cuando una etapa falla, la pipeline se detiene y el cambio no avanza; esa detección temprana es el mecanismo de calidad, no un trámite posterior.

Al final se publica el artefacto con una identificación única y se despliega en un entorno de prueba. La duración total cuenta: si es excesiva, los equipos esperan o acumulan cambios grandes y la retroalimentación llega tarde. Acotar el tiempo, paralelizar lo independiente y reutilizar cachés de dependencias son decisiones de diseño del flujo.

CI, entrega y despliegue en una sola vista

Los tres enfoques comparten la integración automatizada y difieren en qué deciden sobre producción.

Aspecto	Integración continua	Entrega continua	Despliegue continuo
Objetivo	Detectar incompatibilidades poco después de introducirlas	Mantener cada cambio desplegable	Acortar el tiempo hasta el usuario
Resultado inmediato	Cambio validado en la rama compartida	Artefacto versionado listo para publicar	Versión disponible en producción
Quién decide la publicación	No aplica	Una persona o un proceso de aprobación	El propio flujo automatizado
Señal de éxito	Pruebas en verde tras cada cambio	Publicación sin trabajo manual de release	Recuperación posible sin un despliegue inverso complejo
Fallo típico	Pruebas inestables que generan falsas alarmas	Artefactos que nadie llega a publicar	Un defecto visible para todos los usuarios

Herramientas de entrega continua suelen añadir un registro de versiones y un mecanismo de publicación asistido; el despliegue continuo exige además que la aprobación sea automática: pruebas, revisión y presupuesto de error como compuerta. Un equipo puede practicar integración continua sin avanzar hacia las otras dos, pero nadie llega al despliegue continuo sin integración y entrega previas.

Infraestructura como código y automatización

La infraestructura como código (IaC) describe servidores, redes, permisos y servicios en archivos versionados, que se revisan y se aplican de forma repetible. Un enfoque declarativo indica el estado deseado; uno imperativo enumera las acciones. La idempotencia es clave: aplicar la misma definición dos veces no debe duplicar recursos.

La IaC reduce la configuración manual y hace visible la deriva (drift), la diferencia entre lo declarado y lo existente. Permite recrear entornos de prueba similares a producción, pero no elimina la revisión: una definición incorrecta puede borrar recursos. Los secretos se inyectan desde un gestor, no se guardan en el repositorio.

Automatizar tareas repetitivas (toil) libera tiempo para mejorar el sistema. Conviene priorizar lo frecuente, manual y propenso a errores.

Entornos, configuración y promoción

Los entornos representan niveles de confianza distintos: desarrollo, pruebas, staging y producción. Promover significa llevar el mismo artefacto aprobado a un entorno de mayor confianza sin reconstruirlo. Cada nivel puede añadir su configuración —URLs, identificadores de servicios, límites— mediante variables y secretos inyectados al arrancar, de modo que la imagen permanece idéntica en todos ellos.

Las migraciones de esquema merecen una regla propia: se versionan como scripts ejecutables por la pipeline, se aplican antes del código que los necesita y se diseñan para que versiones anteriores y posteriores del servicio convivan durante un despliegue gradual. Un cambio incompatible con el código aún desplegado rompe la promoción aunque las pruebas de la rama pasen.

Los entornos de prueba efímeros, creados para cada solicitud de cambio y eliminados al fusionarla, reducen la colisión entre equipos y mantienen la paridad con producción sin coste permanente. Ese modelo exige que todo dependa de la definición versionada: si un entorno requiere pasos manuales, deja de ser reproducible y la paridad se rompe.

Los datos de prueba se gestionan con criterio: se cargan conjuntos pequeños y sanitizados, nunca una copia literal de producción con información personal. La configuración sensible —claves de API, certificados— llega desde un gestor de secretos con rotación periódica; el repositorio solo contiene la forma de solicitarla.

Seguridad integrada en el flujo

DevOps amplía la responsabilidad compartida al riesgo: quien construye también participa en reducirlo. Integrar comprobaciones de seguridad en la pipeline evita que el análisis sea un cuello de botella al final del ciclo. El análisis estático (SAST) revisa el código sin ejecutarlo; el dinámico (DAST) prueba el servicio ya desplegado; el escaneo de dependencias detecta versiones con vulnerabilidades publicadas en bases de datos públicas.

El análisis de secretos impide que claves y tokens se confirmen en el repositorio, tanto en la revisión local como en el servidor. Un manifiesto de componentes (SBOM) enumera dependencias y versiones de un artefacto, lo que facilita responder con precisión cuando aparece una vulnerabilidad en un componente usado. Firmar imágenes y verificar la firma antes de desplegar cierra el camino entre lo construido y lo ejecutado.

Estas prácticas no sustituyen el diseño seguro ni la revisión de permisos; añaden verificación automática al flujo. El coste de omitirlas aparece tarde, cuando el hallazgo obliga a reconstruir y redesplegar con presión. Invertir en detección temprana es coherente con el principio de integración continua: el problema se ataca donde es más barato corregirlo.

Retroalimentación: métricas DORA, SRE y observabilidad

DORA estudia la entrega con cuatro métricas: frecuencia de despliegue, tiempo de espera de los cambios (change lead time), tasa de fallos en el despliegue y tiempo de recuperación tras un despliegue fallido. Se interpretan en conjunto: desplegar mucho con fallos frecuentes y recuperaciones lentas no es buen resultado. Sirven para mejorar el sistema, no para clasificar personas.

SRE aporta vocabulario operativo. Un SLI es una medida cuantitativa, como la proporción de solicitudes exitosas. Un SLO fija un valor objetivo para ese indicador. Un SLA es un compromiso con consecuencias contractuales. El presupuesto de error es la diferencia tolerada entre el SLO y el 100 %; permite decidir cuánto riesgo asumir al desplegar.

La observabilidad usa logs, métricas y trazas. Los logs registran eventos; las métricas muestran tendencias y permiten alertar; las trazas siguen una solicitud entre servicios. Alertar sobre síntomas que afectan al usuario suele ser más útil que alertar sobre cada causa. Tras un incidente, una revisión sin culpa debe producir acciones concretas.

Flujo de trabajo y medición del valor

DORA describe resultados de entrega; el flujo describe cómo se mueve el trabajo. Tres nociones ayudan: el tiempo de ciclo mide desde que un elemento empieza hasta que entrega valor, el rendimiento indica cuántos elementos terminan por periodo y el trabajo en curso cuenta lo que está empezado pero no terminado. Cuando el trabajo en curso crece, el tiempo de ciclo se dispara porque las tareas esperan en cola.

Reducir el tamaño de los lotes acorta esa cola: un cambio pequeño se revisa, prueba y publica con rapidez, mientras que una entrega masiva concentra el riesgo y hace que la retroalimentación llegue tarde. Limitar el trabajo en curso es una técnica deliberada: el equipo termina antes de empezar, en lugar de repartir atención entre muchas ramas abiertas.

Estas métricas orientan conversaciones de mejora, no clasificaciones individuales. Si el tiempo de ciclo sube, se busca el cuello de botella —revisión, entorno de pruebas, aprobación— y se actúa allí. El objetivo es que la señal de producción retroalimente al equipo con la frecuencia suficiente para corregir rumbo sin gran coste.

Estrategias de despliegue y control del riesgo

Publicar no es solo copiar artefactos: consiste en exponer el cambio con capacidad de revertir. Una actualización por fracciones sustituye réplicas de forma gradual y exige comprobaciones de salud para detener el avance si la versión nueva falla. Un despliegue canary envía un porcentaje pequeño de tráfico a la versión nueva y amplía la fracción solo si las métricas se mantienen; requiere instrumentación capaz de comparar ambas poblaciones.

Un despliegue azul-verde mantiene dos entornos idénticos y conmuta el tráfico de uno a otro; la reversión vuelve a apuntar al entorno anterior, siempre que la migración de datos no haya escrito de forma incompatible. Ese modelo consume el doble de capacidad durante la conmutación y conviene cuando la verificación previa al cambio de tráfico es estricta.

Las banderas de funcionalidad separan la presencia del código de su visibilidad: se despliega con la rama oculta y se activa por población. Su riesgo es el acumulado; una bandera olvidada vuelve el código difícil de razonar, así que conviene caducidad y retiro programado. Ninguna estrategia sustituye una reversión probada: verificar de vez en cuando que el cambio inverso funciona es parte del ensayo, no una señal de derrota.

Los doce factores y la operación en producción

La metodología de los doce factores (12factor.net) reúne prácticas para aplicaciones ejecutadas como servicios. Las más relevantes para DevOps son: declarar y aislar dependencias, guardar la configuración en el entorno, ejecutar procesos sin estado, exponer servicios mediante puertos, tratar los logs como flujos de eventos y mantener paridad entre desarrollo y producción. También distingue build, release y run: la construcción produce un artefacto, la release lo combina con configuración y la ejecución crea procesos.

Estos factores facilitan el escalado y los despliegues repetibles, pero no son una receta universal. Lo importante es reducir diferencias entre entornos, evitar estado local frágil y hacer que la configuración sea explícita.

Toil y automatización con criterio

El toil tiene rasgos reconocibles: es manual, repetitivo, automatizable, consume esfuerzo que no aporta valor duradero y aparece como respuesta a operaciones en lugar de anticiparse. Identificar estos rasgos evita automatizar lo que debería eliminarse: si una tarea existe porque el diseño es frágil, el script perpetúa el problema.

Automatizar tiene coste propio: código que hay que mantener, probar y actualizar cuando cambian las interfaces. Tareas poco frecuentes pueden resolver mejor con una lista de comprobación viva que con un script sin pruebas. La decisión típica es de proporcionalidad: frecuencia y coste del error frente a esfuerzo de construcción y mantenimiento.

Cuando sí se automatiza, la ejecución debe dejar registro, ser reintentable sin efectos parciales y poder detenerse. Un proceso que aplica cambios sin comprobar el estado previo produce sorpresas en el segundo intento. La automatización madura incluye alertas sobre su propio fallo: nadie debe enterarse de que el proceso dejó de correr por una consecuencia tardía en producción.

Resiliencia y práctica deliberada

Los sistemas que operan en producción fallan: dependencias lentas, despliegues defectuosos, saturación de recursos. La preparación no consiste en aspirar a cero incidentes, sino en reducir su impacto y acortar su detección. Inventarios de servicios, dependencias críticas y puntos de contacto hacen que un fallo se asigne al responsable adecuado en minutos.

Las pruebas de resiliencia introducen fallos controlados —cortar una dependencia, simular latencia, retirar una instancia— para descubrir suposiciones incorrectas antes de que lo haga el tráfico real. Se ejecutan con ventana y reversión claras, y cada hallazgo se convierte en tarea concreta: reintento con espera, degradación elegante o límite de carga.

Los ejercicios de recuperación también merecen ensayo: restaurar una copia de seguridad en un entorno aislado demuestra que el procedimiento funciona y revela el tiempo real de recuperación. Un plan de continuidad nunca revisado suele fallar exactamente en el detalle que nadie probó.

Ejemplos prácticos

Un equipo recibe un informe de error. Un desarrollador crea una rama, añade una prueba que reproduce el fallo y confirma el cambio. La pipeline compila el servicio, ejecuta las pruebas y publica una imagen versionada. El mismo artefacto se despliega en un entorno de prueba con verificaciones y métricas.

Si todo pasa, el cambio se promueve gradualmente a producción. El equipo observa errores y latencia; si el presupuesto de error se consume rápido, revierte y analiza el incidente. La configuración se inyecta como variables y secretos; la imagen no se reconstruye. La revisión final añade la validación faltante a la pipeline.

Ejemplo práctico: una corrección con migración de datos

Un equipo detecta que un informe de facturación omite impuestos en ciertos casos. Se crea una rama corta, se añade la prueba que reproduce el cálculo incorrecto y se corrige la lógica. La pipeline ejecuta comprobaciones estáticas, unitarias, de integración y de dependencias, y publica la imagen con una etiqueta derivada del identificador del cambio.

El esquema necesita un campo nuevo, así que la migración se versiona para ejecutarse antes del código que lo lee y para tolerar la versión anterior durante la ventana de despliegue. En el entorno de pruebas se verifica el informe con datos sanitizados y se comprueba que el servicio anterior sigue funcionando con el esquema ya extendido.

La publicación avanza por fracciones: un porcentaje pequeño de tráfico recibe la versión nueva y se comparan errores, latencia y el indicador del informe. Si el presupuesto de error se consume por encima de lo previsto, se detiene el avance y se revierte; después se revisa el incidente buscando la señal que debería haber bloqueado la pipeline. El resultado inmediato no es solo la corrección: la pipeline incorpora la comprobación que faltaba para el próximo cambio similar.

Errores frecuentes

Creer que DevOps es solo un conjunto de herramientas. Comprar una plataforma sin cambiar los flujos ni la responsabilidad compartida no produce los beneficios esperados.
Confundir CI con despliegue continuo. La integración continua valida cambios; no implica que cada cambio llegue automáticamente a producción.
Automatizar sin medir. Una pipeline rápida que no detecta fallos ni mide su efecto sobre los usuarios da una falsa seguridad.
Usar las métricas DORA para evaluar personas. El rendimiento de la entrega depende del sistema y del flujo.
Omitir la paridad entre entornos. Probar con una configuración y desplegar con otra traslada fallos a producción.

Puntos clave para el examen

DevOps integra cultura, automatización, medición y colaboración; no es un producto ni un departamento aislado.
CI integra y valida cambios; la entrega continua mantiene el software desplegable; el despliegue continuo automatiza la llegada a producción.
La IaC versiona la infraestructura, favorece la reproducibilidad y permite detectar deriva.
Las cuatro métricas de DORA se interpretan en conjunto.
SLI, SLO, SLA y presupuesto de error ayudan a decidir cuándo priorizar estabilidad.
Las etapas de una pipeline fallan pronto y detienen el cambio; acotar su duración es parte del diseño del flujo.
Promover un entorno significa reutilizar el artefacto y añadir configuración externa, no reconstruir.
Las estrategias de despliegue —fracciones, canary, azul-verde— limitan el impacto de un defecto; ninguna sustituye una reversión probada.
La seguridad integrada en el flujo detecta vulnerabilidades y secretos antes de que el cambio avance.

Recursos externos

Autoevaluación

¿Qué diferencia principal existe entre entrega continua y despliegue continuo? Respuesta: La entrega deja cada cambio listo para producción, pero el despliegue puede ser manual; el despliegue continuo lo lleva automáticamente tras las validaciones. Justificación: Ambas extienden la CI, pero difieren en qué decide la puesta en producción.
¿Por qué se recomienda promover el mismo artefacto entre entornos? Respuesta: Porque reduce la diferencia entre lo probado y lo ejecutado en producción. Justificación: Reconstruirlo puede introducir dependencias o configuraciones distintas.
¿Qué mide la tasa de fallos en el despliegue de DORA? Respuesta: La proporción de despliegues que requieren una corrección urgente, como un hotfix o una reversión. Justificación: Es una señal de calidad que se lee junto con la frecuencia y el tiempo de recuperación.
¿Para qué sirve un presupuesto de error en SRE? Respuesta: Para decidir cuánto riesgo operativo se puede asumir sin superar el SLO y cuándo priorizar la estabilidad. Justificación: Convierte la fiabilidad en una decisión explícita basada en datos.
¿Qué significa que la configuración debe estar en el entorno? Respuesta: Que los valores que cambian entre despliegues se inyectan externamente, no se codifican en la imagen. Justificación: Permite usar el mismo artefacto sin reconstruirlo.
¿Por qué conviene colocar las pruebas unitarias antes de la construcción? Respuesta: Porque son rápidas y detectan fallos evidentes sin consumir tiempo de compilación ni de etapas posteriores. Justificación: Una pipeline ordena las etapas por coste y por capacidad de fallar pronto.
¿Qué aporta un entorno de prueba efímero? Respuesta: Un espacio aislado creado para cada cambio y eliminado al fusionarlo, sin colisiones entre equipos. Justificación: Se genera desde la definición versionada, lo que preserva la paridad con producción.
¿Cuándo conviene un despliegue canary frente a uno azul-verde? Respuesta: Cuando existe instrumentación para comparar poblaciones y ampliar el tráfico gradual; azul-verde encaja cuando la conmutación total es aceptable y la reversión es inmediata. Justificación: Cada estrategia exige capacidades distintas de observación y de capacidad disponible.
¿Qué problema resuelve un manifiesto de componentes (SBOM)? Respuesta: Permite saber qué dependencias y versiones contiene un artefacto cuando aparece una vulnerabilidad. Justificación: Sin el inventario, localizar el impacto exige reconstruir el conocimiento a mano.
¿Por qué debe caducar una bandera de funcionalidad? Respuesta: Porque el código oculto acumulado vuelve difícil de razonar y de probar el comportamiento real del sistema. Justificación: La bandera separa despliegue y activación, pero exige retiro para no convertirse en deuda.