-pre (DEV) - PROYECTO NEBULAVersión: 1.1.0
Fecha: 2 de Junio, 2026
Estado: NORMATIVO - Despliegue paralelo en DEV
Arquitecto: Carlos Alberto Torres Camargo
El frontend construye e integra contra el contenedor canónico de cada microservicio
en el nodo DEV. Recrear ese contenedor (docker compose up -d --force-recreate) deja al
servicio sin instancias sanas en Eureka durante el arranque de Spring Boot → el gateway
responde 503 → el build del frontend se cae.
La lane -pre permite validar o corregir un cambio desplegando un contenedor
paralelo <servicio>-pre, sin tocar el canónico. Es una herramienta opcional:
el flujo estándar sigue siendo develop → qa → main. Se usa cuando un cambio debe
probarse en DEV sin interrumpir al frontend que está integrando contra el canónico.
La lane
-prese dispara desde la rama permanente opcionalpre, definida en
GitFlow Detallado.
El ruteo en Nebula no es por puerto (los servicios corren con server.port=0,
puerto aleatorio, sin publicar puertos). Es por Eureka + Spring Cloud Gateway:
api-dev.../nebula-accounting-core/api/v1/parametros/read
│
▼ admin.api_route (BD simappe_admin)
path = /nebula-accounting-core/** → uri = lb://NEBULA-ACCOUNTING-CORE
│
▼ Eureka: app NEBULA-ACCOUNTING-CORE
│
▼ servicio con server.servlet.context-path = /nebula-accounting-core
El primer segmento del path es a la vez el routeidentifier en admin.api_route, el
nombre de la app en Eureka y el context-path del servicio. Aislar esos tres elementos
con el sufijo -pre produce una instancia paralela con firma de endpoints idéntica;
solo cambia el primer segmento (/nebula-accounting-core/... → /nebula-accounting-core-pre/...).
Lo único que cambia respecto al canónico es un override de entorno en el contenedor
-pre: SPRING_APPLICATION_NAME=<servicio>-pre. De ahí se deriva todo:
<SERVICIO>-PRE → resuelve la ruta /<servicio>-pre/**.pre-config/<servicio>-pre-dev.yml, que fijacontext-path: /<servicio>-pre y spring.kafka.listener.auto-startup: false.Todo lo demás (BD, tenant, .env, productor de auditoría) es idéntico al canónico.
| Componente | Qué | Dónde |
|---|---|---|
Config -pre |
Copia del YML dev con context-path: /<servicio>-pre y consumers Kafka apagados |
repo SimappeConfig, carpeta pre-config/ |
| Search-paths | El config-server dev incluye pre-config además de dev-config |
env SPRING_CLOUD_CONFIG_SERVER_GIT_SEARCHPATHS=dev-config,pre-config (compose business/server) |
Ruta -pre |
Fila espejo de la canónica con id -PRE y path -pre |
tabla admin.api_route (BD simappe_admin, nodo DEV) |
| Pipeline | Rama pre → DeployHelper.deployPreLane() (contenedor paralelo) |
librería centrica-pipeline-shared (@main) |
Carga de cambios de infra:
pre-config tras reiniciarse (lee de git en cada arranque).admin.api_route tras reiniciarse.Cuando necesites validar o corregir un cambio en DEV sin recrear el canónico:
pre (push directo o MR a pre).pre dispara el pipeline: build, push de imagen (pre-<sha> y latest-dev)docker run <servicio>-pre en dev-network.https://api-dev.centricasoluciones.com/<servicio>-pre/...develop (ver sección 6).La lane aplica solo a servicios nebula-* que tengan su archivo en pre-config/ y su
ruta -pre sembrada en admin.api_route.
develop)Una vez validado en la lane -pre, el cambio se integra por el flujo estándar: se
lleva a develop (merge/MR), cuyo pipeline recrea el contenedor canónico tomando la
imagen latest-dev. De ahí continúa develop → qa → main.
El contenedor
-preno se convierte en canónico (sucontext-pathy nombre de app
son-pre, fijados al arrancar). El canónico se actualiza por su propio flujodevelop.
El-prepuede bajarse una vez validado el cambio.
Recrear el contenedor canónico interrumpe momentáneamente al frontend que construye contra
él. Para no afectar a los equipos, el despliegue al canónico se coordina:
-pre (no recrea el canónico, no requiere ventana).develop → recreación del contenedor) solo en ventanas acordadas con el gatekeeper de frontend.-pre; no se recrea el canónico.Responsables: gatekeeper backend (ejecuta y avisa) · gatekeeper frontend (confirma ventana / pausa integración).
simappe-admin/api/v2/database-config). Las escrituras del -preauto-startup: false): el -pre no consume eventos, así-pre. Si un cambio@KafkaListener, esa ruta no queda cubierta por la lane.El mecanismo es un mini-ambiente efímero autocontenido (nombre de app + context-path +
ruta propios, infra compartida). Parametrizando el sufijo (-pre, -demo, -staging)
se habilitan ambientes de muestra o una eventual pre-producción sin tocar el canónico.
Para aislamiento total (BD/topics propios) se requeriría además un esquema y topics
dedicados; la lane actual usa infra compartida por diseño.
dev-config/<servicio>-dev.yml a pre-config/<servicio>-pre-dev.yml y cambiarcontext-path a /<servicio>-pre y spring.kafka.listener.auto-startup: false.-pre en admin.api_route (espejo de la canónica, id -PRE).centrica-pipeline-shared (la rama pre| Version | Fecha | Autor | Descripcion |
|---|---|---|---|
| 1.1.0 | 2026-06-02 | Carlos Torres | Añadida sección 7: Política de ventanas de despliegue al canónico DEV (coordinación con gatekeeper de frontend). |
| 1.0.0 | 2026-06-02 | Carlos Torres | Creación del documento. Lane -pre para DEV: despliegue paralelo por rama pre, infra (pre-config, api_route, deployPreLane) y promoción a canónico. |