GitHub · config-history
Un repo Git privé à vous pour versionner la config d’infra
(pas les secrets, pas le monorepo app). Projet → repo, simulation → branche,
promote → main, deploy lit toujours la vérité
live / main.
*-infra) = blueprint simulation.
Repo applicatif = code que deploy clone.
On ne mélange pas.
flowchart TB
P[Créer compte / projet] -->|nouveau| R[Repo GitHub privé *-infra]
R --> S[Créer simulation]
S -->|nouvelle| B[Branche sim/nom]
B -->|push configs| B
B -->|promote| M[main = stack live]
M -->|deploy apps| D[Cloud Outscale]
M -->|rollback snapshot| B2[État précédent + plan/apply]
La logique en quatre gestes
1 · Créer un projet / lier le tenant —
bige-ops peut créer un nouveau repo GitHub privé
(config-history) ou s’attacher à un repo existant
(config_repo sur le compte). C’est le coffre Git de la stack,
pas l’app métier.
2 · Créer une simulation —
variante locale (layout, €, generate). Au push :
nouvelle branche sim/<id>.
Vous itérez sans toucher la prod déclarative.
3 · Promote une simulation —
la draft devient live (stack live). Côté Git : alignement sur
main. Option simulation promote --push-main.
Un snapshot pré-promote permet de revenir en arrière sur la config.
4 · Deploy — le déploiement applicatif / la stack active s’adosse à la live, donc à la ligne main du config-history. On ne déploie pas « une branche random » : main = ce qui est promu.
| Action locale | Effet GitHub config-history |
|---|---|
| Nouveau projet / bind | Repo privé créé ou lié |
| Nouvelle simulation (draft) | Branche sim/<id> |
| Push depuis draft | Commit sur sim/… |
| Promote (+ push-main) | Live + main à jour |
| Deploy | Référence live / main |
| Rollback snapshot | Restore fichiers locaux → plan/apply cloud |
Branches : pourquoi c’est cool (et imparfait)
Cool.
Une simulation = une branche sim/<id> : vous itérez,
comparez, review, sans écraser la vérité live. Promote aligne
main = ce qui est déployable. L’historique GitHub devient
la mémoire du blueprint (qui a changé quoi, quand) — utile pour
auditer et pour repartir d’un commit connu.
Imparfait. Ce n’est pas un GitOps complet ni un « undo one-click » cloud. L’app pousse / promeut via GitHub ; elle ne gère pas encore les conflits complexes, les PR riches, ni les autres forges. Si un push / promote / sync rate, ou si vous devez revenir loin : ouvrez GitHub (revert, checkout d’un commit, force-alignement de branche), puis resync / plan / apply dans bige-ops. Les snapshots locaux aident, mais le filet de sécurité « vérité Git » reste manuel sur GitHub pour l’instant.
Deploy via l’app · sync GitHub
Le chemin nominal : vous validez dans l’app (Visual / Workspace /
Change review) → deploy / apply côté Outscale, et la
config d’infra est synchronisée sur votre repo GitHub
(branches sim/… ou main selon le geste).
Pas de backend bige-ops qui garde votre Git : c’est votre
compte GitHub, piloté depuis le desktop.
Autres Git : WIP. Pas de sync native GitLab / autre pour le moment. Vous pouvez toujours versionner hors outil, mais bige-ops ne « drive » que GitHub aujourd’hui.
Emulate deploy & rollback
Avant d’engager le cloud, vous émulez : simulation +
estimate + generate + plan. Le GitHub config-history
versionne ces états sur sim/… pour comparer, review, CI légère.
Rollback dans l’app = restaurer un
snapshot de simulation (simulation rollback),
puis plan / apply pour réconcilier le cloud.
Ce n’est pas un « undo magique Outscale ».
Rollback Git (secours) — si l’état local / la sync
est foireux : allez sur GitHub, reprenez un commit
ou une branche saine (main / sim/…), puis
ramenez la config dans la simulation et rejouez plan/apply.
Lien mental : GitHub = source de vérité versionnée ; Outscale = effet
cloud après apply.
sequenceDiagram
participant Dev as Vous
participant Sim as Simulation
participant GH as GitHub main/sim
participant Cloud as Outscale
Dev->>Sim: draft + push
Sim->>GH: sim/feature
Dev->>Sim: promote
Sim->>GH: main
Dev->>Cloud: apply / deploy
Dev->>Sim: rollback snapshot
Sim->>Cloud: plan + apply réconciliation
Ce qui part / ne part jamais
Poussé (config-history) : project.yaml,
terraform sans tfvars, oks, scripts app, layout Visual,
.env.example, SECRETS.md.
Exclu : credentials, PEM, .env, tfvars,
kubeconfigs, state, inventory, sources app clonées.
Voir aussi le bloc sécurité sur la
landing.
Repos applicatifs : clonés au deploy, jamais commités automatiquement par bige-ops. Dockerfile dans le repo ou override dans la stack — détail repos · VMs · Dockerfiles.
Défauts & versions à venir
Convention branches live→main / draft→sim/… : déjà le défaut. Création repo à la volée, push Hub, promote --push-main : en place. À durcir ensuite : UX « emulate deploy » plus visible, rollback guidé depuis le Hub, garde-fous destroy (ex. OOS), et la revue diffs / commits en mode expert — feuille de route.
Mode expert (édition fichiers) : expert-config.html. Retour data : bases · OOS & backups.