Projet final — gère le dépôt d’infrastructure d’une PME

01Comprends le besoin

État initial
- main : version livrée ;
- dev : branche d’intégration ;
- configuration staging suivie ;
- CI minimale ;
- contribution par pull request.

Demande
Ajouter un runbook de sauvegarde avec validation,
état attendu et rollback.

02Livrables obligatoires

repository/
├── .github/workflows/ci.yml
├── ci/check.sh
├── config/platform.conf
├── docs/
│   ├── CONTRIBUTING.md
│   ├── BACKUP_RUNBOOK.md
│   └── RELEASE_1.0.0.md
├── evidence/
│   ├── issue.md
│   ├── pull-request.md
│   ├── review.md
│   ├── ci-before-merge.txt
│   ├── ci-after-merge.txt
│   ├── ci-release.txt
│   └── FINAL_CHECKLIST.md
├── .gitignore
└── README.md

03Contraintes de gouvernance

- feature basée sur dev ;
- commits atomiques et lisibles ;
- aucun commit direct ordinaire sur main ;
- revue avant intégration ;
- CI réussie avant et après merge ;
- fusion explicite de dev vers main ;
- tag annoté v1.0.0 ;
- aucun secret, log ou artefact suivi ;
- rollback documenté.

04Exécute le laboratoire de référence

lab=/tmp/soria-git-release-ci-$USER
script=module5-git-release-ci-project.sh

bash "$script" setup "$lab"
bash "$script" status "$lab"
bash "$script" run "$lab"
bash "$script" validate "$lab"

Lis ensuite le graphe et les preuves. Ne considère pas la validation automatique comme un substitut à ton explication.

05Construis ta propre histoire

git switch dev
git switch -c feature/backup-runbook
# commits séparés : runbook puis preuves
git log --oneline --decorate --graph --all
git diff dev...HEAD

Le diff doit rester centré sur la demande. Toute correction de configuration non liée devient une autre issue et une autre branche.

06Produis les preuves de décision

Issue
- problème ;
- critères d’acceptation.

Pull request
- base et head ;
- changements ;
- validation ;
- rollback ;
- limites.

Review
- risque examiné ;
- remarque traitée ;
- SHA approuvé.

07Valide la sécurité du dépôt

git status --ignored --short
git ls-files '.env' 'artifacts/**' '*.log'
git grep -n -I -E \
  'ghp_|github_pat_|password[[:space:]]*=|token[[:space:]]*=' \
  HEAD -- . || true
bash ci/check.sh

Une recherche sans résultat est une preuve partielle, pas une garantie absolue. Explique les limites et les contrôles de plateforme complémentaires.

08Prépare la release

git switch main
git merge --no-ff dev \
  -m "merge: release infrastructure baseline"
bash ci/check.sh
git tag -a v1.0.0 \
  -m "Infrastructure baseline 1.0.0"
git show --no-patch v1.0.0

09Démontre le rollback

Scénario
Le runbook contient une commande erronée après release.

Réponse attendue
- identifier le commit ;
- ouvrir une correction ou revert ;
- repasser la CI ;
- publier une nouvelle version ;
- ne pas déplacer v1.0.0.

10Critères d’acceptation

11Définition de terminé

[ ] le lab validate retourne 0
[ ] les working trees sont propres
[ ] main contient dev et la feature revue
[ ] les merges attendus ont deux parents
[ ] v1.0.0 est un tag annoté
[ ] les preuves CI sont présentes
[ ] aucun secret ou artefact interdit n’est suivi
[ ] la procédure de rollback est exploitable
[ ] le reset du lab est exécuté

bash "$script" reset "$lab"
test ! -e "$lab"