← Accueil · Périmètre

GitHub · config-history

Un repo Git privé, à toi, pour versionner la config d’infrastructure (ni les secrets, ni le code applicatif). Projet → repo, simulation → branche, promote → main ; le deploy s’appuie toujours sur la simulation live, donc sur main.

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 compte — bige-ops peut créer un repo GitHub privé (config-history) ou se rattacher à 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, coût, generate). Au push : nouvelle branche sim/<id>. Tu itères sans toucher à la stack live.

3 · Promouvoir une simulation — la draft devient live. Côté Git : alignement sur main, avec simulation promote --push-main. Un snapshot pris avant le promote permet de revenir sur la config.

4 · Deploy — le déploiement s’adosse à la simulation live, donc à la branche main du config-history : on déploie ce qui est promu.

Avec un token GitHub et un config-history lié, l’app pousse automatiquement la config d’une simulation sur sa branche après chaque Save (les sauvegardes rapprochées sont regroupées). Elle ne supprime jamais de branche distante.

Les branches

Ce qu’elles apportent. Une simulation = une branche sim/<id> : tu itères, compares, relis, sans toucher à la stack live. Le promote aligne main sur ce qui est déployable. L’historique GitHub devient la mémoire de la stack (qui a changé quoi, quand) : utile pour auditer et repartir d’un commit connu.

Ce qui se fait sur GitHub. La synchro couvre le push, la création de branches et le promote ; les résolutions de conflits et les pull requests se mènent sur GitHub. Si une synchro échoue, ou pour revenir loin en arrière : ouvre GitHub (revert, checkout d’un commit, réalignement de branche), puis resync, plan et apply dans bige-ops.

Deploy via l’app, sync GitHub

Le chemin nominal : tu valides dans l’app (Visual, Workspace, revue des changements) → deploy / apply côté Outscale, et la config d’infrastructure est synchronisée sur ton repo GitHub (branches sim/… ou main selon le geste). Aucun backend bige-ops ne garde ton Git : c’est ton compte GitHub, piloté depuis le desktop.

Simuler le deploy, revenir en arrière

Avant d’engager le cloud, tu simules : simulation + estimation + generate + plan. Le config-history versionne ces états sur sim/… pour comparer, relire, brancher une CI légère.

Rollback dans l’app = restaurer un snapshot de simulation (simulation rollback), puis plan / apply pour réconcilier le cloud.

Rollback Git — si l’état local ou la synchro ne convient plus : sur GitHub, reprends un commit ou une branche saine (main / sim/…), ramène la config dans la simulation et rejoue plan/apply. Repère : GitHub = la config versionnée ; Outscale = l’effet dans le cloud après apply.

sequenceDiagram
  participant Dev as Toi
  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 de réconciliation
      

Ce qui part, ce qui ne part jamais

Poussé (config-history) : project.yaml, Terraform sans tfvars, specs OKS, scripts app, layout Visual, .env.example, SECRETS.md. Exclu : credentials, PEM, .env, tfvars, kubeconfigs, state, inventaire, sources app clonées. Détail : secrets & coffre.

Repos applicatifs : clonés au deploy, jamais commités automatiquement par bige-ops. Dockerfile dans le repo ou chemin imposé par la stack — détail repos · VMs · Dockerfiles.

La suite

Convention main pour la live, sim/… pour les drafts, création de repo à la volée, push et promote --push-main : en place. Prochaines étapes : un « deploy simulé » plus visible, un rollback guidé depuis le Hub, et la revue des diffs et commits en mode expert — mode expert.

Mode expert (édition des fichiers) : expert-config.html. Data : bases · OOS & backups.