Qué es deploy (despliegue): tipos, proceso y buenas prácticas

En este artículo
  1. Los entornos por los que pasa el código
  2. Las fases de un despliegue
  3. Tipos de despliegue
  4. Buenas prácticas
  5. Herramientas habituales
  6. Un ejemplo sencillo con GitHub Actions
  7. Preguntas frecuentes

Hacer deploy (o despliegue) es llevar el código desde el entorno donde lo desarrollas hasta el servidor donde lo usan las personas reales. Es el momento en que tu trabajo deja de ser un experimento en tu ordenador y pasa a estar en producción.

Suena a copiar archivos, y en su versión más primitiva lo es. Pero un despliegue mal hecho tumba un servicio, y por eso existe todo un conjunto de técnicas alrededor.

Los entornos por los que pasa el código

Antes de entender el despliegue hay que entender por dónde viaja el código:

EntornoPara qué esQuién lo usa
LocalEscribir y probarCada desarrollador en su equipo
DesarrolloIntegrar el trabajo del equipoEl equipo técnico
Staging / PreproducciónCopia fiel de producciónPruebas y validación del cliente
ProducciónEl sistema realLos usuarios finales

La clave está en staging: debe parecerse a producción lo máximo posible. Si en staging usas una base de datos con diez registros y en producción hay dos millones, esa prueba no te está diciendo lo que crees.

Las fases de un despliegue

  1. Construcción (build). El código se compila, se minifican los archivos, se optimizan las imágenes y se empaqueta todo.
  2. Pruebas automáticas. Se ejecutan los tests. Si alguno falla, el despliegue se detiene aquí.
  3. Migraciones de base de datos. Se aplican los cambios de estructura. La fase más delicada de todas.
  4. Publicación. Los archivos nuevos sustituyen a los antiguos en el servidor.
  5. Verificación. Comprobaciones automáticas de que el sistema responde correctamente.
  6. Monitorización. Vigilar errores y rendimiento durante los minutos siguientes.

Tipos de despliegue

Despliegue directo

Se para el servicio, se suben los archivos y se vuelve a arrancar. Es lo más simple y lo más arriesgado: hay interrupción, y si algo falla el servicio se queda caído mientras lo arreglas.

Válido para proyectos pequeños o si despliegas de madrugada. No para un servicio con usuarios activos.

Rolling (progresivo)

Con varios servidores, se van actualizando de uno en uno. Mientras uno se actualiza, los demás siguen atendiendo. No hay corte de servicio.

Su inconveniente: durante unos minutos conviven dos versiones distintas, así que ambas deben ser compatibles entre sí.

Blue-green

Mantienes dos entornos idénticos. Uno (azul) está activo y el otro (verde) recibe la versión nueva. Cuando está lista y verificada, se cambia el enrutamiento de golpe.

Su gran ventaja es la marcha atrás: si algo falla, se vuelve al entorno anterior en segundos, porque sigue intacto. El coste es mantener el doble de infraestructura.

Canary (canario)

Se envía la versión nueva a un porcentaje pequeño de usuarios, por ejemplo el 5%. Si las métricas de error se mantienen bien, se amplía al 25%, al 50% y al 100%. Si empeoran, se revierte y solo se vio afectada una minoría.

Es el método más seguro para servicios grandes, y el nombre viene de los canarios que los mineros llevaban para detectar gases.

Feature flags

Más que un tipo de despliegue, es una técnica complementaria: el código nuevo se sube pero permanece desactivado tras un interruptor. Se activa cuando quieres, para quien quieres, y se apaga sin necesidad de desplegar nada.

Separa el despliegue del lanzamiento, que son dos cosas distintas y que mucha gente confunde.

Buenas prácticas

Automatiza el proceso. Si desplegar requiere quince pasos manuales, algún día alguien se saltará uno. Con integración y despliegue continuos, el proceso se ejecuta igual siempre.

Despliega pequeño y a menudo. Es contraintuitivo, pero desplegar cambios pequeños cada día es mucho más seguro que acumular un mes de trabajo. Cuando algo falla en un cambio pequeño, sabes exactamente qué lo causó.

Ten siempre marcha atrás. Antes de desplegar, responde: si esto sale mal, ¿cómo vuelvo atrás y cuánto tardo? Si no tienes respuesta, no despliegues.

Copia de seguridad antes de tocar la base de datos. Sin excepciones. Revertir código es fácil; revertir datos borrados, no.

Migraciones compatibles hacia atrás. Si vas a eliminar una columna, hazlo en dos despliegues: primero deja de usarla, y solo cuando la versión nueva esté estable, elimínala. Si borras y necesitas revertir, la versión anterior se encuentra sin esa columna.

Variables de entorno, nunca credenciales en el código. Las contraseñas y claves de API van en configuración del servidor, fuera del repositorio.

No despliegues un viernes por la tarde. Es un chiste recurrente entre desarrolladores y no es solo un chiste: si algo falla, hay menos gente disponible y más horas hasta que alguien lo detecte.

Vigila después de desplegar. Los primeros quince minutos son los importantes. Si te vas sin mirar los registros de error, te enterarás del fallo por un cliente enfadado.

Herramientas habituales

CategoríaEjemplos
Automatización (CI/CD)GitHub Actions, GitLab CI, Jenkins
ContenedoresDocker, Kubernetes
Plataformas gestionadasVercel, Netlify, Railway, Render
Infraestructura como códigoTerraform, Ansible
MonitorizaciónSentry, Datadog, Grafana

Si estás empezando, las plataformas gestionadas resuelven el despliegue casi entero: conectas tu repositorio y cada vez que subes cambios a la rama principal, despliegan solas.

Un ejemplo sencillo con GitHub Actions

name: Desplegar

on:
  push:
    branches: [main]

jobs:
  desplegar:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Instalar dependencias
        run: npm ci
      - name: Ejecutar pruebas
        run: npm test
      - name: Construir
        run: npm run build
      - name: Publicar
        run: ./scripts/deploy.sh

Cada vez que alguien sube cambios a main, se instalan dependencias, se ejecutan las pruebas y, solo si pasan, se construye y se publica. Si una prueba falla, el despliegue se detiene y nadie tiene que acordarse de comprobarlo.

Preguntas frecuentes

¿Deploy y release son lo mismo?
No. El deploy pone el código en el servidor; el release lo hace visible para los usuarios. Con feature flags puedes desplegar hoy y lanzar la semana que viene.

¿Cada cuánto conviene desplegar?
Cuanto más a menudo, mejor. Los equipos maduros despliegan varias veces al día. La frecuencia alta reduce el riesgo de cada despliegue.

¿Qué es un rollback?
Volver a la versión anterior. Debe ser rápido y estar probado, no improvisado en mitad de una incidencia.

¿Se puede desplegar sin cortar el servicio?
Sí, con rolling, blue-green o canary. El despliegue directo es el único que implica interrupción.


¿Quieres entender cómo funciona el desarrollo profesional? En nuestro catálogo de cursos técnicos tienes formación desde cero, con acceso inmediato y de por vida.