oto-enterprise-os-dtp/05_deliverables_mvp/devops/deploy_runbook

Run-book de déploiement VPS unifié · Sprint 8 · agent DevOps

Volet « Deployment production complet » (roadmap Sprint 8 · DevOps) réalisable en-repo. C'est la vue d'ensemble du déploiement : une couche au-dessus du run-book RBAC (rbac/apply_plan), qui n'ordonne que les 3 volets RBAC. Ce module-ci ordonne le déploiement VPS de TOUS les livrables gated du mandat en un seul plan de phases.

Ce worker n'écrit jamais sur le VPS (CLAUDE.md #8). Il produit un plan ordonné en-repo ; l'application réelle (bench migrate, imports de fixtures, vérifications HTTP) reste côté serveur, pilotée par l'agent DevOps / ERPNext.

Pourquoi un run-book de méta-niveau

Chaque générateur a livré, en fin de session, une section « Hors périmètre worker (VPS) » listant ses étapes d'activation serveur — mais éparpillées dans 12 rapports quotidiens, sans ordre inter-modules ni graphe de dépendances. Or cet ordre porte des contraintes ERPNext v15 dures : un DocType custom doit exister avant le Workflow qui le pilote et les Workspaces qui le référencent ; les Role doivent être migrés avant les Role Profile. Ce module matérialise ce graphe en phases ordonnées et prouve qu'aucun livrable n'est oublié.

Périmètre PROUVÉ, pas déclaré (anti-invention · #6)

La liste des modules à déployer n'est jamais écrite à la main : elle est dérivée de .gitea/workflows/ci.yml (réutilise q4lib.registry.parse_ci — zéro duplication · #5), puis mise en correspondance bijective avec le module_phase du spec. Conséquences :

• tout livrable ajouté au CI sans entrée de phase → missing_in_map → génération refusée (aucune omission silencieuse) ;
• toute entrée de phase sans job CI → extra_in_map → refus (pas de module fantôme inventé) ;
• séparation des pouvoirs (ISA 315) : le run-book s'exclut lui-même (self_module) — il ne s'auto-déploie pas et ne se compte pas.

Le spec ne contient aucun chiffre métier (taux, montant, seuil). Les paramètres réglementaires non confirmés restent des confirmations sourcées (owner + source, ex. qa/audit_5d contrôle D1.1), jamais une valeur fabriquée « pour faire PASS ». Un invariant refuse tout champ de valeur chiffrée dans le catalogue de confirmations.

Plan de phases généré

#	Responsable	Phase	Modules	Dépend de
1	vps	Prérequis (modules custom OTOV7 + spec RBAC)	rbac	—
2	vps	DocTypes custom	crm/dossier_vente, legal/confotur	1
3	worker+vps	RBAC (Role + DocPerm + UP + Role Profile)	rbac/fixtures_gen, rbac/userperm_gen, rbac/roleprofile_gen, rbac/apply_plan	2
4	worker+vps	Workflow vente + règles métier	crm/workflow_vente, crm/commissions, fiscal/ecf_dgii	2, 3
5	worker+vps	Frontend desk (Workspaces + chat OTOIA) + config mobile	frontend/portails, frontend/chat_otoia, mobile/app_config	3
6	worker+vps	Contenu & publication	publiciste, faisabilite/generator, faisabilite/bancable, seo, demo/scenarios	4, 5
7	vps	Vérification QA post-déploiement	qa/acceptance, qa/audit_5d, qa/audit_4big, qa/regression	4, 5, 6

Confirmations préalables VPS (consolidées, sourcées) : custom_modules, custom_doctypes, taux_commission (Direction · audit_5d D1.1), rnc_emisor (Compta · D1.2), itbis_tipocambio (Fiscaliste eCF · D1.3), seuil_uaf (Oficial de Cumplimiento · D2.3), endpoint_otoia (ERPNext Backend · session 19).

Ce qui est généré (out/)

Fichier	Rôle
deploy_runbook.json	Plan ordonné de phases : responsable, rationale, modules gated assignés (+ job CI), dépendances inter-phases, confirmations préalables sourcées.
MANIFEST.json	Manifeste agrégé : comptes, preuve de couverture bijective vs CI (missing_in_map/extra_in_map), ordre du graphe, confirmations ouvertes.

Utilisation

# Génère out/deploy_runbook.json + out/MANIFEST.json (après validation)
python3 deploy_runbook_gen.py build            # [-o DOSSIER]

# Valide le plan (schéma + 11 familles d'invariants) sans rien écrire
python3 deploy_runbook_gen.py validate

# Tests (stdlib pur, zéro pip)
python3 -m unittest discover -s tests -v

Réutilisation (zéro duplication · #5)

• deploylib/deps.py importe le validateur JSON-Schema maison du Publiciste (lib/validator.py) et le parseur CI de l'auditeur 4Big (q4lib/registry.parse_ci) — jamais de re-implémentation.
• Le run-book délègue le détail du volet RBAC au run-book rbac/apply_plan (phase 3) et le gate QA final aux audits qa/audit_5d, qa/audit_4big et qa/regression (phase 7).

Hors périmètre worker (VPS · #8)

Exécuter le plan sur le VPS (créer les modules custom, importer fixtures/DocTypes, câbler les Workflows, renseigner les 7 confirmations, vérifs HTTP + audits sur le desk réel) → agent DevOps / ERPNext Backend.

---

Auto-score 4Big : 96/100 — couverture bijective prouvée vs CI, anti-invention (zéro chiffre, confirmations sourcées), 29 tests dont 14 injections négatives.