Files
bdt-cli/README.md

122 lines
4.3 KiB
Markdown

# BDT CLI (`bdt`)
Shell de operaciones de la plataforma BDT: clona los repositorios desde el GitLab del banco, compila los servicios, construye sus imágenes Docker y los levanta con docker compose. Incluye menú interactivo y asistente guiado de construcción.
## Requisitos
- bash 3.2+ (macOS o Linux)
- git
- Docker + Docker Compose v2
- Java 21 (JDK) — para compilar gateway / service-bus
- Node.js 20 — para el frontend (solo si se compila fuera de Docker)
## Instalación
```bash
git clone https://git.dcgeeks.net/BDT/bdt-cli.git
cd bdt-cli
./bdt.sh setup # instala el comando global 'bdt' + autocompletado + alias
```
O descarga directa del script:
```bash
curl -fsSL https://git.dcgeeks.net/BDT/bdt-cli/raw/branch/main/bdt.sh -o bdt.sh
chmod +x bdt.sh
./bdt.sh setup
```
> `setup` guarda la raíz del proyecto en `~/.bdt/project-root`. Ejecutalo desde el directorio donde van a vivir los repositorios de la plataforma (el script clona `backend/`, `frontend/`, `infrastructure/`, etc. relativo a esa raíz).
## Configuración
El script lee `~/.bdt/config` al arrancar (las variables de entorno tienen prioridad):
```bash
# GitLab del banco
GITLAB_URL=http://gitlab.bicentenariobu.com.ve
GITLAB_GROUP=dcgeeks
# Ambiente por defecto (desarrollo|calidad|demo|produccion)
DEFAULT_ENV=desarrollo
# Servidor de deploy remoto (comando server-deploy)
DEPLOY_SERVER=<ip-del-servidor>
DEPLOY_USER=<usuario-ssh>
```
Credenciales git (para que `clone`/`pull` no pidan contraseña):
```bash
bdt git-auth <usuario-gitlab>
```
## Uso rápido
```bash
bdt # menú interactivo
bdt construir # asistente: elegir servicio + rama → git → build → docker → up
bdt deploy # pipeline completo: pull → compilar → imágenes → up → health
bdt status # estado de servicios y contenedores
bdt health # health check completo
bdt logs gateway -f # seguir logs de un servicio
bdt help # ayuda completa
bdt self-update # en el server: git pull bdt-cli + reinstalar enlace
bdt deploy-jar gateway # JAR en /tmp → docker build → up (server)
```
### Actualizar el shell en el server del banco
El script vive en su propio repo git (`bdt-cli`), separado del monorepo de aplicaciones:
```bash
# Primera vez (o migrar desde la copia suelta /opt/bdt-platform/bdt.sh):
bdt self-update
# Después de cada release publicado con `bdt publish`:
bdt self-update
```
`self-update` clona o hace `git pull` en `/opt/bdt-platform/bdt-cli` (configurable con
`BDT_CLI_DIR` en `~/.bdt/config`), reinstala `/usr/local/bin/bdt` y arregla permisos de logs.
Repos:
- Gitea: `https://git.dcgeeks.net/BDT/bdt-cli`
- GitLab banco (VPN): `http://gitlab.bicentenariobu.com.ve/dcgeeks/bdt-cli`
Publicar una versión nueva desde desarrollo:
```bash
# En el monorepo BDT, después de editar bdt.sh:
./bdt.sh publish # commit + push a Gitea y GitLab del banco
```
### Asistente `construir` (opción `0` del menú)
Flujo guiado para construir y desplegar **un** servicio:
1. Pregunta qué servicio construir (frontend, gateway, service-bus, canales-admin-web, canales-worker) mostrando rama por defecto y estado del contenedor.
2. Pregunta la rama (Enter = rama por defecto del servicio).
3. Muestra el plan y pide confirmación.
4. Ejecuta: descarga de la rama desde el GitLab del banco → `gradle bootJar` (solo servicios Java) → `docker build``docker compose up -d --force-recreate` → health check.
Si hay cambios locales sin commitear, ofrece guardarlos en stash antes de cambiar de rama.
## Servicios gestionados
| Servicio | Stack | Rama default | Puerto |
|---|---|---|---|
| frontend | Next.js | develop | 59002 |
| gateway | Spring Boot | develop | 58050 |
| service-bus | Spring Boot | develop | 58060 |
| canales-admin-web | Next.js (pnpm) | master | 58180 |
| canales-worker | Node (pnpm) | master | 59091 |
Infraestructura (postgres, redis, redpanda, keycloak, mailpit, prometheus, grafana) se levanta con `bdt up infra`.
## Notas
- Los servicios Java se compilan con `gradle bootJar` **antes** del `docker build` (el Dockerfile copia `build/libs/*.jar`). Frontend y canales compilan dentro del Docker build (multi-stage).
- El nombre del remote que apunta al GitLab del banco puede variar por repositorio; el script lo detecta automáticamente por URL.
- Logs de compilación en `<raíz>/logs/`.