odoo-forge · visión objetivo e historial de plataforma

Actores, control plane y flujos objetivo

Esta página conserva la visión de plataforma y su contexto histórico; no describe componentes desplegados hoy.

Existe / con base hoy Nuevo — a construir

Estado actual implementado

Hoy existen la CLI forge, el núcleo puro, puertos de código, workspace, backend, imágenes y base de datos; adaptadores para Git, workspace, Docker local, GHCR y PostgreSQL Docker aislado. La fuente actual es la guía de implementación actual.

Estado objetivo e histórico — no implementado

Regla dura Solo corre lo que vive en un repositorio. Nada se despliega fuera de git → CI.
Reusar infra vía puertos & adaptadores Un adaptador por puerto, elegido al init Guardar punteros, no copias Estado anti-drift (registro canónico único)

Actores y sus recorridos

1Desarrollador Jronboarding — entorno rápido
pideinstancia por cliente al control plane
→
recibecódigo + BD randomizada de ese cliente
→
desarrollalocal, editable
→
pusha repositorio
→
CIsi pasa ↓
→
serverbuildea imágenes + CD a servidores
2DevOpsoperación de despliegues
vecontrol panel: instancias por server
→
decideaplicar update al server correspondiente
→
CI/CDcontra copia de BD pre-productiva
→
si pasadespliega en el server (EC2/VPS/Fargate/K8s)
3Usuarios del control planefuncional · devops · customer · CTO — según permisología (RBAC)
solicitainstancia PROD nueva
·
solicitainstancia QA generada desde una PROD
·
solicitainstancia DEV randomizada para testing de flujos

Puertos & adaptadores — reusar infra, elegir 1 al init

git ✓

SourceProvider

Código de módulos/Odoo.

GitHub · GitLab · repos externos

SP-1 ✓

ImageRegistryProvider

Imágenes Docker por digest.

GHCR · GitLab · ECR · DockerHub

SP-2

DatabaseProvider

El adaptador PostgreSQL Docker aislado ya existe; RDS y VPS PG siguen como objetivo.

PostgreSQL Docker · RDS · VPS PG

4b ✓

BackendProvider

Puerto existe (docker local, 4b); adaptadores remotos = SP-3.

Docker local · EC2/VPS · Fargate · K8s

SP-5

IdentityProvider

Auth/RBAC (reusado, no se construye).

GitHub · GitLab · Google (OIDC)

SP-6

PipelineProvider

CI/CD (reusado, no se construye).

GitHub Actions · GitLab CI

Control plane — qué debe contener para servir eso

forge serverAPI + RBAC · recibe peticiones

La autoridad central. Toma código de repos, fabrica, decide y entrega. Mantiene el registro canónico de instancias (estado) y reconcilia contra el backend (línea 227: preguntarle al backend, nunca un registro que derive).

SP-4

Registro canónico de instancias

Estado: qué corre, dónde, qué versión — reconciliado contra el backend.

SP-5

API + permisología (RBAC)

Vía IdentityProvider (OIDC/SSO). Quién puede pedir qué.

SP-6

Integración CI/CD

Dispara/lee PipelineProvider; push→CI→build→CD.

SP-1 ✓

Fábrica + registry de imágenes

Build por capa, pinneado por digest. Supersede el PublishedLayer deprecado (§8).

SP-3

Orquestador de deploy multi-target

Sobre BackendProvider; Docker local existe y los destinos remotos siguen como objetivo.

SP-2

Ciclo de vida de BDs

Provisión, clonado, randomización, copias pre-prod.

SP-7

Entrega de código fuente

Servida a devs. Base: SourceProvider+git (2b) + workspace projection (3).

SP-10

Gobernanza & ciclo de vida

Audit trail append-only · guardrails PROD · GC/retención · orquestación de backups.

Targets de despliegue — cada uno es un BackendProvider

4b ✓

Docker local

Hecho (Slice 4b).

SP-3

EC2 / VPS

VM directa.

SP-3

Fargate

Contenedor gestionado.

SP-3

Kubernetes

Orquestado.

Ciclo de vida de las BDs (por defecto anonimizado)

PROD → QA (clon)

QA desde una prod puntual — anonimizada salvo autorización auditada.

PROD → DEV (randomizada)

Datos anonimizados para devs / testing.

Copia pre-productiva

El CI/CD de DevOps corre contra esta (anonimizada) antes de desplegar.

✓ Nota de diseño — estado en el server

El server central con estado NO contradice el diseño fundacional. Lo anticipan la línea 187 ("canonical-ID instance registry — principle from day 1") y la 228 ("Control plane (Phase 4): PostgreSQL — real server-side state"). El "no database" de la línea 227 era solo para el CLI core. La línea 195 ("web SQLModel schema") es el patrón dual-DDL abandonado ("Consciously left behind") — el drift a NO repetir (cicatriz del mer-fk-refactor).

Multi-fase. Descomposición completa (SP-1..SP-10) en el roadmap maestro: docs/specs/2026-07-08-platform-roadmap.md.