5.4Despliegue y CI/CD (Render, Railway, VPS)
Lo esencial en 30 segundos
- Desplegar = poner en línea : hacer correr la app en un servidor accesible — PaaS simple para empezar, VPS para el control.
- CI/CD = entrega auto : en cada push, probar (CI) y luego desplegar si todo pasa (CD) — fin del despliegue manual arriesgado.
- Secretos fuera del código : config y secretos en variables de entorno — nunca en el código ni en Git.
Mini-caso hilado — Salim pone en línea en Argel
La API contenerizada de Salim corre bien — pero solo en los puestos del equipo en Argel. La despliega en una plataforma : repositorio conectado, variables de entorno informadas en la plataforma, HTTPS activo. Luego añade un pipeline : en cada push, los tests corren, y el despliegue sigue solo si pasan. Último episodio de los casos 5.1-5.3 — Salim entrega un verdadero servicio en línea.
Último episodio de los casos 5.1-5.3 — Salim cierra tipado, rendimiento y Docker con la puesta en producción.
1. Desplegar : PaaS o VPS
El despliegue hace correr la aplicación en un servidor accesible en Internet (en vez de localhost). Las plataformas PaaS lo simplifican todo : se conecta su repositorio Git, la plataforma construye, lanza, gestiona servidor, HTTPS y escalado básico — con un nivel de entrada accesible para empezar — ideales para empezar. En el otro extremo, un VPS (servidor virtual alquilado) da más control pero más responsabilidades : instalar Node, configurar, asegurar, gestionar PM2, un reverse proxy, el HTTPS — más complejo, pero formador. Las grandes nubes ofrecen una paleta potente con curva de aprendizaje. Salim empieza por una PaaS : su API está en línea siguiendo la documentación de la plataforma, sin administrar servidor.
Recomendación : PaaS para poner sus proyectos en línea rápido, VPS para aprender la administración o ganar control, nube para necesidades avanzadas.
2. CI/CD y esenciales de producción
El CI/CD automatiza el camino código → producción. La integración continua : en cada push, un pipeline lanza los tests y el linting para detectar problemas pronto. El despliegue continuo : si todo pasa, el código se despliega automáticamente. GitHub Actions crea estos pipelines. Beneficios : automatización (más gestos manuales fastidiosos), fiabilidad (nada roto va a producción), rapidez (entregar a menudo con confianza), trazabilidad (cada despliegue ligado a un commit). Esenciales : variables de entorno (config + secretos, nunca en el código/Git), HTTPS, logs y monitorización, entornos separados (dev/staging/prod). Salim escribe su primer pipeline : instalar, probar, desplegar si verde — es la culminación, no solo crear sino entregar.
Incluso simple, un pipeline lo cambia todo : los tests ya nunca se « olvidan » antes de un despliegue.
3. Elegir sin equivocarse
El compromiso fundamental : simplicidad contra control. PaaS : simplicidad extrema, menos control fino, dependencia de la plataforma — perfecto para empezar y muchos proyectos. VPS : control total y flexibilidad, pero usted lo gestiona todo (seguridad, actualizaciones, copias) — formador, más exigente. Para un prototipo o un ejercicio, un despliegue manual basta ; en cuanto un proyecto es serio, se despliega regularmente o en equipo, incluso un CI/CD simple aporta valor real. Salim compara las ofertas de los alojadores (fórmulas y límites que cambian a menudo, verifica la documentación actual al elegir) y hace validar la elección de infraestructura sensible por su DSI antes de exponer datos reales.
En todo caso, los esenciales quedan : secretos en variables de entorno, HTTPS, logs y monitorización, entornos separados.
🔎 Ejemplo concreto — El pipeline de Salim
En cada push : instalar, probar, desplegar si verde.
# GitHub Actions (.github/workflows/ci.yml)
# en cada push :
# npm install → npm test → desplegar si verde
# secretos y config : variables de entorno de la plataforma
# PaaS : construye desde el repositorio, HTTPS autoLectura : el pipeline es la puerta : nada roto pasa.
Lección : los secretos viven en el entorno, nunca en el código.
Vocabulario de la sección
- Despliegue
- Hacer correr la app en un servidor accesible en Internet.
Ejemplo sencillo: La API de Salim deja localhost por una dirección pública.
Lo que no es: copiar archivos a mano sin pipeline.
Reflejo: ¿mi app es accesible fuera de mi puesto?
- PaaS
- Plataforma que construye y aloja la app desde el repositorio Git.
Ejemplo sencillo: Salim conecta su repositorio, la plataforma gestiona servidor y HTTPS.
Lo que no es: un servidor que se administra uno mismo.
Reflejo: ¿necesito control, o simplicidad?
- VPS
- Servidor virtual alquilado que se administra uno mismo.
Ejemplo sencillo: Salim instalaría ahí Node, PM2 y el HTTPS él mismo.
Lo que no es: una plataforma que gestiona la infraestructura.
Reflejo: ¿estoy listo para asumir seguridad y mantenimiento?
- CI/CD
- Pipeline que prueba en cada push y despliega si todo pasa.
Ejemplo sencillo: El push de Salim dispara tests y luego puesta en línea auto.
Lo que no es: un despliegue manual a base de comandos.
Reflejo: ¿un push puede ir a prod sin tests?
- Variables de entorno
- Config y secretos aportados por el entorno, fuera del código.
Ejemplo sencillo: La clave de Salim vive en la plataforma, nunca en Git.
Lo que no es: un secreto escrito en duro en el código.
Reflejo: ¿un secreto ronda por mi repositorio?
En la práctica — Desplegar y automatizar una aplicación
- Despliegue una aplicación Node en una plataforma PaaS simple : conecte su repositorio Git, la plataforma construye y lanza la aplicación, con HTTPS.
- Configure las variables de entorno en la plataforma (secretos, config) — nunca en el código ni Git.
- Ponga un pipeline CI/CD (GitHub Actions) : en cada push, lanzar los tests y desplegar automáticamente si todo pasa.
- Asegure los esenciales de producción : HTTPS, logs/monitorización, y entornos separados (dev/staging/prod).
Guion listo para decir — anunciar la puesta en línea
« Nuestra API está lista para salir de localhost : la despliego en una plataforma — repositorio conectado, secretos en variables de entorno, HTTPS activo. Añado un pipeline simple : tests en cada push, despliegue solo si todo pasa. Antes de exponer datos reales, hago validar la elección de infraestructura por la DSI. »
Para decir al responsable para hacer validar la puesta en línea y el circuito DSI en datos sensibles.
Modelo copiar-pegar — pipeline CI genérico
name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- run: npm install
- run: npm testSolo / presupuesto pequeño
Salim solo : una PaaS + un pipeline que prueba en cada push basta — ningún servidor que administrar.
Pyme / equipo reducido
Entornos dev y prod separados, secretos en la plataforma : cada push probado antes de la puesta en línea.
Pyme en Argel
Salim hace validar el alojador y los accesos por la DSI en Argel antes de exponer datos reales de clientes.
Equipo que empieza
Pareja : uno escribe el pipeline, el otro verifica secretos y HTTPS ; revisión antes del primer despliegue auto.
✓ Buenas prácticas
- Empezar con una plataforma PaaS : simple, HTTPS gestionado.
- Poner config y secretos en variables de entorno (nunca en Git).
- Automatizar tests + despliegue con un pipeline CI/CD (GitHub Actions).
✗ Errores frecuentes
- Poner secretos en el código o el repositorio Git.
- Desplegar sin HTTPS (contraseñas y datos en claro).
- Desplegar manual y a ciegas (sin tests automatizados previos).
Puntos clave
- DESPLIEGUE : hacer correr la app en un servidor accesible (en vez de localhost). PaaS (simple) o VPS/nube (más control).
- CI/CD (GitHub Actions) automatiza código → producción : CI (probar en cada push), CD (desplegar si todo pasa). Automatización, fiabilidad, rapidez, trazabilidad.
- Esenciales de producción : VARIABLES DE ENTORNO (config + secretos, nunca en el código/Git), HTTPS, logs/monitorización, entornos separados.
- Es la culminación del recorrido : no solo CREAR una aplicación, sino ENTREGARLA — un servicio real, en línea, fiable.
Reto 48h — aplica mañana
Despliegue 1 app en una plataforma (repositorio conectado + HTTPS) con sus secretos en variables de entorno : ¿un push dispara los tests?
- Puedo explicar CI frente a CD en una frase.
- Mi app está en línea (HTTPS) sin secreto en Git.
- Sé cuándo pasar de PaaS a VPS.
Preguntas frecuentes
PaaS, VPS o nube : ¿cómo elegir dónde desplegar mi aplicación Node?
Según su necesidad y su nivel. Las plataformas PaaS simplifican enormemente : se conecta su repositorio Git, la plataforma construye y lanza la aplicación, gestiona el servidor, el HTTPS y el escalado básico — ideales para empezar y para muchos proyectos. Un VPS (servidor virtual alquilado) da más control pero más responsabilidades : usted lo administra todo (Node, PM2, reverse proxy, HTTPS) — más complejo, pero formador. Las grandes nubes ofrecen una paleta potente con curva de aprendizaje. Recomendación : empiece por una PaaS para poner sus proyectos en línea ; pase al VPS para aprender la administración ; explore la nube para necesidades avanzadas. Compare las ofertas al elegir (cambian) y haga validar por la DSI antes de exponer datos sensibles.
¿Por qué poner un CI/CD, y es necesario para pequeños proyectos?
El CI/CD automatiza el camino del código a la producción : CI (en cada push, el pipeline verifica — tests, linting), CD (si todo pasa, despliegue auto). Beneficios : automatización (fin de lo manual fastidioso y arriesgado), fiabilidad (nada roto va a producción), rapidez (entregar a menudo con confianza), trazabilidad (cada despliegue ligado a un commit). Para un prototipo desechable, no estrictamente necesario. En cuanto un proyecto es serio, se despliega regularmente o en equipo, incluso un pipeline simple aporta valor real. Empiece simple : instalar, probar, desplegar si todo pasa.
¿Qué hace un pipeline CI/CD?