Lanza versiones a staging y production con confianza: este flujo con Now, Jenkins y Docker crea un deployment por cada lanzamiento, genera una URL nueva y permite alternar vía DNS. Así aislas cambios, reduces riesgos y conectas tu pipeline para decidir si pasas a producción.
¿Cómo funciona el deployment con Now, URLs y DNS?
Now publica el código y devuelve una URL única por deployment. Puedes tener decenas o cientos de versiones y apuntar por DNS a la correcta. El cambio de DNS no es inmediato para todos: algunos clientes verán la versión anterior por un tiempo limitado. A nivel de los “bounce” sería inmediato, pero Now no ofrece eso en este contexto. Para estos objetivos es suficiente.
Cada deployment genera una URL nueva.
Puedes alternar entre versiones por DNS.
La propagación de DNS tarda un poco.
¿Qué preparar en Now y Jenkins antes de desplegar?
Primero, crea tu cuenta en Now, entra a Account > Account Settings y genera un token. En Jenkins, añade este token como credencial de tipo secret text y nómbralo, por ejemplo, nowToken. Ese credencial se inyecta solo en los jobs donde lo asocias.
¿Cómo añadir credenciales y variables seguras en Jenkins?
Ir a la página de credenciales y agregar tipo secret text.
Nombrar y referir la variable como nowToken.
Inyectar el credencial solo en el job que lo requiera.
¿Qué plugin y paquetes globales necesitas?
En “Global Configuration Tool”, buscar instalaciones de No JS.
Si falta, instalar el plugin de No JS.
Agregar el paquete global Now. Now es un binario disponible en los builds cuando se usa esa versión.
¿Cómo se configura el entorno de Node y npm?
Usar “provide node en npm en el path”.
Seleccionar la versión “once punto cero punto uno punto cero”.
¿Cómo automatizar el deployment a staging desde el Jenkinsfile?
Se crea un job tipo freestyle project llamado “Deploy WebApp Staging” (WebApp es el repositorio; Staging el ambiente). Aunque aquí se muestra freestyle, la recomendación es usar Jenkinsfile.
¿Qué pasos incluye el job de Deploy WebApp Staging?
Aceptar un parámetro: artifact ID.
Borrar el workspace antes de empezar. Es una buena práctica y aquí es clave.
Añadir “secret text or file” e inyectar nowToken.
Proveer node y npm en el path con la versión indicada.
Ejecutar un shell que cree el Dockerfile y llame a Now con el token.
Ejemplo de fragmentos (replican lo dicho, no agregan lógica nueva):
# Crear Dockerfile a partir del artifact IDecho"from ${ARTIFACT_ID}"> Dockerfile
# Desplegar con Now usando token (alias -t de --token)now -t "$nowToken"
Now detecta el Dockerfile, crea un deployment tipo Docker, lo envía a su cloud y devuelve una URL.
¿Cómo se conecta el job de deploy desde el Jenkinsfile?
En el repositorio “Plazy Scripts”, carpeta “web app”, se define: “schedule staging deployment when branch is master”. Solo se lanza a staging si el build está en master y está verde. Si fallan tests o build, no corre el stage de staging.
Fragmento ilustrativo del Jenkinsfile con parámetros y sin espera bloqueante:
artifact ID ya se había guardado como variable de entorno del job.
wait: false evita que el CI espere a que termine el deployment.
¿Qué verás al ejecutar el flujo completo?
Desde web app en master, corre build y tests.
Se programa “Deploy WebApp Staging” con éxito.
En el job de deploy: recibe el parámetro (por ejemplo, “3”), crea el archivo, Now “pulleea” la imagen del repositorio (p. ej., “Vue ocho web app” con su tag), muestra “Build completed, verifying instantiation” y lanza.
La URL queda activa. Un endpoint simple “add 1 + 2” responde “3”.
Luego, se pueden correr tests contra esa URL para decidir si pasar a production.
¿Tienes dudas o quieres compartir cómo ajustas tu pipeline con wait: false y staging? Comenta y conversemos.
