bige-ops Beta démo

Projets, simulations & promote

Tout est local et hiérarchique : un workspace sur votre poste, des comptes Outscale dedans, des simulations dans chaque compte. Une simulation est live, les autres sont des brouillons — jusqu’au promote.

Le modèle

flowchart TB
  W[Workspace sur votre poste] --> A[Compte = un tenant Outscale]
  A --> C[credentials et inventory et shared.yaml]
  A --> S1[Simulation live]
  A --> S2[Simulation draft]
  S2 -->|promote| S1
  S1 -->|archivee| S3[Archive]

Le compte porte ce qui est partagé ; la simulation porte ce qui est jetable.

Niveau	Sur disque	Contient
Workspace	un dossier de votre choix	vos comptes
Compte	`accounts/<id>/`	credentials, inventaire, `shared.yaml`
Simulation	`accounts/<id>/simulations/<name>/`	la stack, le YAML, les artefacts générés

Live et draft

Simulation live — existing/, ou celle que vous avez promue. C’est la stack de travail, celle orientée prod, celle qui correspond à ce que vous appliquez sur le compte.
Simulation draft — une variante en parallèle. Vous cassez, vous testez, vous comparez le coût. Elle ne remplace rien tant que vous ne faites pas promote.

Convention Git. La simulation live pousse sur la branche main du config-history. Une simulation draft ou archivée pousse sur sim/<slug>. Détail : GitHub config.

Les commandes

bige-ops account list
bige-ops account add
bige-ops account show
bige-ops account shared-add
bige-ops account shared-list

bige-ops simulation list
bige-ops simulation create
bige-ops simulation ensure
bige-ops simulation clone
bige-ops simulation promote
bige-ops simulation archive

bige-ops simulation snapshot
bige-ops simulation snapshots
bige-ops simulation rollback --snapshot <id> --dry-run

bige-ops diff config
bige-ops workspace migrate

Promote

promote marque la simulation courante comme live et archive la précédente. Par défaut, un snapshot de l’ancienne live est pris avant — coupez-le avec --no-snapshot si vous savez ce que vous faites. Avec --push-main, les configs partent sur la branche main du dépôt de config-history.

cd accounts/<id>/simulations/ma-variante
bige-ops simulation promote            # snapshot auto + archive de l’ancienne live
bige-ops simulation promote --push-main

Snapshots, rollback, diff

snapshot capture l’état de la configuration, snapshots les liste, rollback --snapshot <id> revient dessus (essayez d’abord avec --dry-run). diff config compare le YAML courant à un snapshot. C’est un filet local sur la config, rien de plus.

Rollback de la config ≠ rollback du cloud. Un rollback remet vos fichiers YAML dans un état antérieur. Il ne défait rien sur Outscale. Revenir en arrière côté infrastructure veut dire re-plan puis re-apply, et parfois un destroy — avec les risques de perte de données que cela implique. Le rollback Git côté GitHub, lui, reste manuel.

Ce que ça n’est pas

Pas un système de versioning de votre infrastructure réelle : le seul état de vérité du cloud, c’est le compte Outscale et le state Terraform.
Pas de merge entre simulations. On promeut ou on archive ; on ne fusionne pas deux drafts.
Pas de workflow multi-équipe avec verrous. Le workspace est local, mono-poste ; la coordination passe par Git, à votre main.
Pas un remplacement de votre process de release. C’est un kickoff — périmètre.

Historique Git : GitHub config. YAML brut : config expert. Lire le compte existant : inventaire & import. Objet et backups : OOS. Définition : glossaire · promote.