Desplegar, subir, aplicar — significado de los términos y diferencias

Qué significa «desplegar», «subir», «aplicar»

«Desplegar» es el término más general que significa publicar una nueva versión de un producto de software, funcionalidad o cambio. «Desplegamos una actualización», «desplegamos una corrección», «desplegamos un lanzamiento» — en todos los casos, el cambio está disponible para los usuarios. El término implica una acción bastante grande: normalmente se despliega una versión completa, no un solo archivo.

«Subir» es un término más específico que significa cargar archivos, datos o artefactos a un servidor o almacenamiento. «Subir el build al servidor», «subir scripts a la BD», «subir assets al CDN». A diferencia de «desplegar», el término no implica que lo subido esté disponible para los usuarios — los archivos pueden estar en el servidor pero aún no conectados a la aplicación. Matiz: «subir» también se usa para enviar código a un repositorio («subido a GitHub»).

«Aplicar» es un término que significa aplicar un cambio sobre una versión existente. «Aplicar una migración», «Aplicar un parche», «Aplicar una configuración». La diferencia clave es que el cambio se superpone sin reemplazo completo. Si «desplegar» es lanzar una nueva versión en lugar de la anterior, «aplicar» es agregar un cambio a lo que ya funciona. El término es común en el contexto de bases de datos (migraciones) y lanzamientos de parches.

Términos adicionales del mismo campo semántico: «distribuir» (propagar un cambio a todos los servidores del clúster), «revertir» (volver a la versión anterior), «derramar» (desplegar accidentalmente la versión incorrecta). Todos estos verbos describen acciones con el código como si fuera un objeto físico que se puede «rodar», «verter» y «retroceder».

Origen de los términos informales

El término «desplegar» proviene de una metáfora automotriz: «desplegar un coche del garaje». Cuando el código está listo para su lanzamiento, se «despliega» — se saca, se hace accesible a los usuarios. La metáfora se extendió a principios de los 2000 con la llegada de las prácticas de entrega continua, cuando los lanzamientos se volvieron regulares en lugar de anuales. «Hoy tenemos día de despliegue» significa el día del lanzamiento.

El término «subir» tiene raíces en los inicios de la web, cuando los sitios se subían a los servidores por FTP. «Subir archivos al servidor» — literalmente transferir archivos mediante un protocolo asociado con «verter» datos. La palabra se consolidó, aunque el despliegue moderno usa pipelines CI/CD en lugar de clientes FTP. Dato curioso: en inglés, el equivalente es «push» (push to server), no «pour». El idioma ruso eligió una metáfora diferente.

El término «aplicar» proviene del entorno de producción: «aplicar una rueda», «enroscar una tuerca». En el contexto del software — superponer un cambio sobre un sistema existente, como enroscar una rosca en un perno. En bases de datos el término es especialmente orgánico: las migraciones se «aplican» y se «revierten». Rollback es uno de los pocos términos ingleses que tiene un equivalente exacto en ruso: «otkat».

Diferencia entre los términos en diferentes contextos

En el contexto de bases de datos: las migraciones se «aplican», los datos se «suben», la versión del esquema se «despliega». Si necesitas agregar una nueva columna — aplicas una migración. Si necesitas insertar datos de prueba — subes un volcado. Si cambia toda la estructura de la BD — despliegas un nuevo esquema. La diferencia refleja distintas operaciones: apply, insert/load, deploy.

En el contexto de DevOps: «desplegar» — ejecutar un pipeline, «subir» — cargar una imagen Docker a un registro, «aplicar» — aplicar una configuración a un servidor mediante Ansible. Ejemplo: «primero subimos la imagen al registro, luego aplicamos la configuración al servidor, y solo entonces desplegamos el lanzamiento». Cada término corresponde a una etapa separada del pipeline CI/CD.

En el contexto de desarrollo móvil: «subir» — enviar un build a App Store Connect o Google Play Console, «desplegar» — publicar en la tienda de aplicaciones, «aplicar» — entregar una actualización mediante el mecanismo de actualizaciones dentro de la aplicación. Para iOS, «desplegar» significa pasar la revisión; para Android, el despliegue gradual mediante Play Console. Escala de tiempo: «subir» toma minutos, «desplegar» toma horas o días (debido a la revisión).

Etapas del proceso de lanzamiento: del commit a producción

Etapa 1: Compilación (Build). El código se compila, se ensambla un artefacto (binario, imagen Docker, APK/IPA). El servidor CI ejecuta la compilación tras cada commit en la rama principal. El resultado de la compilación es un artefacto listo para desplegar con una etiqueta de versión única (versionamiento semántico o hash del commit). Si la compilación falla — todo el pipeline se detiene, el desarrollador recibe una notificación.

Etapa 2: Pruebas (Test). Se ejecutan pruebas unitarias, de integración, linters y verificaciones de seguridad (SAST). Esta etapa no debe durar más de 10–15 minutos — si es más, los desarrolladores pierden el contexto y se cambian a otras tareas. La retroalimentación rápida es un principio clave de CI/CD. Según Puppet State of DevOps 2023, los equipos con pruebas rápidas (<10 min) hacen 3 veces más lanzamientos.

Etapa 3: Despliegue en staging (Staging Deploy). El artefacto se despliega en un entorno de staging idéntico a producción. En staging se ejecutan pruebas E2E, pruebas smoke y, si es necesario, pruebas manuales de QA. Si se detecta una regresión en staging, el lanzamiento se bloquea y los cambios se envían para revisión.

Etapa 4: Despliegue en producción (Production Deploy). El artefacto se despliega en los servidores de producción. Dependiendo de la estrategia de despliegue (rolling, blue-green, canary), la implementación puede durar desde segundos hasta horas. Después del despliegue se ejecutan pruebas post-deploy y monitoreo — si las métricas son normales, el lanzamiento se considera exitoso. La reversión automática cuando se supera el umbral de errores es una práctica estándar.

Estrategias de despliegue: rolling, blue-green, canary

Rolling deploy — actualización de servidores uno por uno. Mientras un servidor se actualiza, los demás siguen atendiendo a los usuarios. Tras la actualización exitosa del primer servidor, se actualiza el segundo, y así sucesivamente. Desventaja: durante el despliegue, diferentes versiones funcionan en diferentes servidores, lo que puede causar incompatibilidad. Ventaja: zero-downtime y no se necesita el doble de servidores.

Blue-green deploy — dos entornos idénticos: Blue (versión actual) y Green (nueva versión). Una vez que Green está completamente listo y probado, el balanceador de carga cambia el tráfico de Blue a Green. Si se detecta un problema en Green — se vuelve a Blue. Ventaja: reversión instantánea. Desventaja: se necesitan el doble de recursos (servidores) para mantener dos entornos. El cambio toma segundos.

Canary deploy — la nueva versión se despliega primero en un pequeño porcentaje de servidores (5–10%). Algunos usuarios obtienen la nueva versión, el resto permanece en la anterior. Si las métricas en el grupo canary son normales (la tasa de error no aumentó, la latencia no creció), la nueva versión se implementa gradualmente en todos los servidores. Google, Netflix, Spotify usan canary deploy para minimizar riesgos. Desventaja: complejidad del monitoreo y análisis de métricas.

Herramientas de automatización de despliegue

Servidores CI/CD — Jenkins, GitLab CI, GitHub Actions, CircleCI, Bitrise (para móvil). Se eligen según el stack: Jenkins es universal, GitLab CI si el repositorio está en GitLab, Bitrise para iOS/Android. La tarea principal de un servidor CI/CD es ejecutar automáticamente el pipeline de compilación, pruebas y despliegue sin intervención humana.

Contenedores — Docker, Kubernetes. Docker crea contenedores aislados con la aplicación y todas las dependencias. Kubernetes gestiona el despliegue de contenedores en un clúster de servidores: actualización rolling automática, escalado, balanceo de carga. Según la encuesta CNCF 2023, el 96% de las organizaciones usan contenedores en producción, de las cuales el 67% usa Kubernetes.

Infrastructure as Code — Terraform, Ansible, Pulumi. Terraform describe la infraestructura (servidores, redes, balanceadores) como código y gestiona su estado. Ansible se encarga de la configuración de servidores: instalación de software, ajuste de parámetros. La combinación Terraform + Ansible proporciona una infraestructura completamente automatizada: Terraform crea los servidores, Ansible los configura. Infraestructura inmutable — los servidores no se actualizan, sino que se reemplazan por otros nuevos con una imagen actualizada.