Qué es deploy (despliegue): tipos, proceso y buenas prácticas
En este artículo
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:
| Entorno | Para qué es | Quién lo usa |
|---|---|---|
| Local | Escribir y probar | Cada desarrollador en su equipo |
| Desarrollo | Integrar el trabajo del equipo | El equipo técnico |
| Staging / Preproducción | Copia fiel de producción | Pruebas y validación del cliente |
| Producción | El sistema real | Los 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
- Construcción (build). El código se compila, se minifican los archivos, se optimizan las imágenes y se empaqueta todo.
- Pruebas automáticas. Se ejecutan los tests. Si alguno falla, el despliegue se detiene aquí.
- Migraciones de base de datos. Se aplican los cambios de estructura. La fase más delicada de todas.
- Publicación. Los archivos nuevos sustituyen a los antiguos en el servidor.
- Verificación. Comprobaciones automáticas de que el sistema responde correctamente.
- 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ía | Ejemplos |
|---|---|
| Automatización (CI/CD) | GitHub Actions, GitLab CI, Jenkins |
| Contenedores | Docker, Kubernetes |
| Plataformas gestionadas | Vercel, Netlify, Railway, Render |
| Infraestructura como código | Terraform, Ansible |
| Monitorización | Sentry, 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.