OVERVIEW ARCHITETTURA DB (Bitwall DEV CRM)
🎯 Obiettivo del sistema

Gestire:

applicazioni (progetti)
ambienti (dev, staging, prod)
server (web + database)
credenziali (sicure)
deploy / sync / backup
stato e versioni

👉 Il CRM è il control plane, non esegue operazioni
👉 Gli agent eseguono (deploy, db sync, ecc.)

🧱 STRUTTURA LOGICA (LIVELLO ALTO)
APPLICAZIONE
   ↓
AMBIENTI (env)
   ↓
SERVER + DB SERVER
   ↓
CREDENTIAL
   ↓
OPERAZIONI (deploy, sync, backup)
📦 1. APPLICAZIONI
bm__applicazioni
Ruolo

Anagrafica progetto

Campi principali
id
nome
codice
shortname
id_framework
versione_app
repo_locale
dir
id_circuito
attivo
NOTE

⚠️ NON contiene più configurazione tecnica runtime (DB, FTP ecc.)
(legacy ancora presente ma da dismettere)

🌍 2. AMBIENTI (CORE DEL SISTEMA)
bm__app_env
Ruolo

Configurazione runtime per ogni ambiente

👉 una app può avere:

dev
staging
prod
local
Campi principali
id
id_applicazione
nome
tipo (dev, staging, prod)
id_server_web
id_db_server
path_remoto
url_principale
db_name
db_user
id_credential_db
id_credential_deploy
id_framework
versione_framework
versione_app
branch
online
attivo
Relazioni
bm__app_env.id_applicazione → bm__applicazioni.id
bm__app_env.id_server_web → bm__server.id
bm__app_env.id_db_server → bm__db_server.id
bm__app_env.id_credential_db → bm__credential.id
🖥️ 3. SERVER
bm__server
Ruolo

Server web / hosting

Campi
id
nome
ip
hostname
porta_ssh
root
tipo
is_storage
bm__db_server
Ruolo

Server database separato

Campi
id
nome
host
porta
engine
versione
🔐 4. CREDENTIAL (CRITICO)
bm__credential
Ruolo

Gestione centralizzata segreti

Campi
id
nome
tipo (db, ftp, ssh, api)
username
secret_encrypted
iv_encrypted
cipher
scope
attivo
NOTE IMPORTANTI
❌ NON usare più password in chiaro
✔ usare cifratura (AES)
✔ chiave fuori dal DB

👉 best practice: separare accessi e limitare privilegi

🔗 5. LINK CREDENTIAL
bm__credential_link

Permette associazione flessibile:

credential → env
credential → server
credential → db server
📊 6. STATO AMBIENTE
bm__app_env_status
Ruolo

Snapshot veloce per dashboard / agent

Campi
id_app_env
last_code_version
last_db_version
last_deploy_at
last_db_sync_at
last_result
last_message
🧬 7. MIGRATIONS
bm__migration

Definizione migrations disponibili

bm__app_env_migration

Storico execution per ambiente

👉 fondamentale per:

upgrade sicuri
evitare doppia esecuzione
🚀 8. JOB / OPERAZIONI
bm__deploy_log
Ruolo

Storico operazioni eseguite

Campi
id_app_env
operazione (deploy, db_sync, backup)
trigger_type (manual, agent, cron)
versione_codice
versione_db
started_at
ended_at
esito
output_log
📦 9. BACKUP
bm__backup_job

Configurazione backup

bm__backup_log

Storico backup

📝 10. NOTE
bm__nota
Ruolo

Knowledge base operativa

Esempi
“non fare deploy diretto in prod”
“svuotare cache prima di update”
⚙️ 11. SETTINGS
bm__setting

Configurazioni globali

🔄 FLUSSO OPERATIVO (IMPORTANTE PER CODEX)
🔹 Recupero configurazione app
getAppEnv($appId, $env)

→ restituisce:

[
  'server' => ...,
  'db' => ...,
  'credentials' => ...,
  'paths' => ...
]
🔹 Deploy
legge bm__app_env
legge credential
rsync files
log su bm__deploy_log
🔹 DB Sync
legge bm__app_env
connette DB
esegue migrations
aggiorna:
bm__app_env_status
bm__app_env_migration
🧠 PRINCIPI ARCHITETTURALI (IMPORTANTE PER AI)

Questo schema segue best practice:

✔ separazione ambienti (dev/staging/prod)
✔ normalizzazione dati (no duplicazioni)
✔ gestione versioni DB
✔ separazione credenziali
✔ logging completo
🎯 COSA DEVE FARE IL BACKEND (per Codex)
Deve smettere di usare:
bm__applicazioni.db_*
bm__applicazioni.ftp*
server_address
Deve usare:
bm__app_env
+ bm__credential
+ bm__server
+ bm__db_server
Pattern consigliato

👉 unico punto di accesso:

AppEnvResolver::get($appId, $env)
🚀 CONCLUSIONE

Codex deve:

centralizzare la config su bm__app_env
usare bm__credential per segreti
ignorare campi legacy
introdurre resolver unico
usare deploy_log per logging