Vai al contenuto

Portale di sviluppo Git

Questa procedura separa il lavoro degli agent dalla produzione.

Obiettivo

  • Produzione: /home/safeops/safeops, servizio safeops-web.service, porta 18081.
  • Sviluppo: /home/safeops/safeops-dev, branch dev/safeops-20260819, porta 18082.
  • Gli agent lavorano sul portale di sviluppo e registrano sempre il lavoro in Agent Workspace.
  • La produzione riceve solo modifiche validate e portate con Git.

Regole operative

  1. Non lavorare direttamente su /home/safeops/safeops salvo emergenze esplicite.
  2. Prima di iniziare, aprire o selezionare una scheda in Agent Workspace.
  3. Lavorare in /home/safeops/safeops-dev.
  4. Validare con test mirati, git diff --check e, se toccate le docs, mkdocs build --strict.
  5. Portare in produzione solo patch revisionate.

Setup iniziale

La worktree dev è stata creata con:

cd /home/safeops/safeops
git worktree add /home/safeops/safeops-dev -b dev/safeops-20260819 HEAD

La porta prevista per Gunicorn dev è 127.0.0.1:18082.

Configurazione ambiente

Creare il file runtime fuori dal versionamento:

cd /home/safeops/safeops-dev
mkdir -p deploy/env
cp deploy/examples/safeops-dev.env.example deploy/env/safeops-dev.env
chmod 600 deploy/env/safeops-dev.env

Poi compilare DATABASE_URL, REDIS_URL e SAFEOPS_AGENT_WORKSPACE_TOKEN.

Attenzione: per prove operative non usare il database produzione. Se il DB dev non è ancora pronto, limitarsi a test statici, lint, build docs e test unitari senza scritture.

Installazione servizio dev

Quando il DB dev è pronto:

cp /home/safeops/safeops-dev/deploy/systemd/safeops-dev.service.example /etc/systemd/system/safeops-dev.service
systemctl daemon-reload
systemctl start safeops-dev.service
systemctl status safeops-dev.service

Nginx dev

Il vhost esempio è:

/home/safeops/safeops-dev/deploy/nginx/safeops-dev.conf.example

Va installato come configurazione dedicata solo quando DNS e servizio dev sono pronti.

Flusso per agent

Prompt operativo minimo:

Lavora solo in /home/safeops/safeops-dev.
Prima leggi Agent Workspace e seleziona lo slug del lavoro.
Non toccare /home/safeops/safeops.
Non riavviare safeops-web.service.
Usa safeops-dev.service solo se il lavoro richiede il portale dev.
Alla fine registra evento, test eseguiti, file toccati e blocchi.

Promozione verso produzione

Prima di scegliere cosa portare in produzione generare sempre il report read-only:

cd /home/safeops/safeops-dev
python scripts/dev_prod_alignment_report.py

Lo script scrive una cartella in:

/home/safeops/tmp/dev_prod_alignment/<run_id>/

con:

  • manifest.json: stato completo dei file modificati nei due ambienti;
  • report.md: riepilogo leggibile per revisione e Agent Workspace.

Il report non modifica file, non copia contenuti e non riavvia servizi.

La promozione avviene solo dopo:

git status --short
git diff --check
python -m py_compile <moduli_toccati>
pytest <test_mirati>

Per documentazione:

mkdocs build --strict

La patch verso produzione deve essere piccola, collegata a una scheda Agent Workspace e reversibile.

Protocollo stabile DEV -> produzione

  1. Generare il report scripts/dev_prod_alignment_report.py.
  2. Scegliere un solo pacchetto funzionale, per esempio compila_v3, non_conformities, print_engine, tecnico_files.
  3. Verificare il diff dei file del pacchetto confrontando DEV e produzione.
  4. Eseguire su DEV i test mirati del pacchetto.
  5. Preparare backup timestamp dei file produzione da modificare.
  6. Applicare in produzione solo la patch selettiva approvata.
  7. Validare produzione con py_compile, parse Jinja se ci sono template, git diff --check e test mirati.
  8. Riavviare solo i servizi coinvolti.
  9. Registrare evento Agent Workspace con:
  10. ticket/workspace;
  11. file promossi;
  12. test eseguiti;
  13. backup/rollback;
  14. rischi residui.

Non usare copia globale DEV -> produzione. Se un file e' modificato in entrambi gli ambienti con contenuto diverso, va trattato come conflitto da leggere a mano.