Wiki/.claude/workflows/release.md

Workflow : RELEASE PROD

Process de release semver vers production. Cf doc 17 section 4.

Trigger

• Ensemble de stories mergees sur main, pretes pour prod
• Corentin decide "on release" → tag semver

Acteurs

• Corentin (decisionnaire + approbateur)
• bridge-tester (validation E2E staging)
• acadenice-devops (deploy + watch + rollback si besoin)
• (optionnel) Yan (approbateur backup pour deploy prod)

Pre-requis

• Tous les CI sur main = vert
• Tests E2E staging = vert
• Backup recent (< 24h) verifie
• Pas de creneau metier critique (cours en cours, deadline saisie heures)

Sequence

[1] Decision release (Corentin)
    - Lister les commits sur main depuis derniere release : git log v<last>..HEAD --oneline
    - Decider type release : MAJOR / MINOR / PATCH (semver)
    - Output : decision + version cible

[2] Update CHANGELOG.md (Corentin OU bridge-dev assist)
    - Deplacer section [Unreleased] vers nouvelle section [vX.Y.Z]
    - Ajouter date
    - Verifier que toutes les entries sont la
    - Commit : `docs(changelog): release vX.Y.Z`
    - Output : CHANGELOG.md a jour

[3] E2E tests staging (bridge-tester via CI)
    - Trigger : push sur main fait deja le deploy staging auto
    - Verifier : workflow e2e.yml passe (Playwright sur staging URL)
    - Si fail : retour fix avant release
    - Output : E2E status

[4] Validation manuelle staging (Corentin)
    - Tester quelques flows critiques sur staging URL :
      * Login Docmost
      * Creation page + share link
      * Saisie heures realisees (UC-13)
      * Creation projet + tache (UCA-02 + UCA-03)
    - Output : sign-off staging

[5] Backup verification (acadenice-devops)
    - Verifier dernier backup < 24h existe
    - Optionnel : declencher backup ad-hoc avant deploy prod
    - Output : backup verifie

[6] Tag semver + push (Corentin)
    - git tag -a vX.Y.Z -m "Release vX.Y.Z — <one-liner>"
    - git push origin vX.Y.Z (ou push selfhost selon source of truth)
    - Trigger : workflow deploy-prod.yml se declenche
    - Output : tag prod cree

[7] Approval review (Yan ou Corentin)
    - GitHub UI : environment 'production' demande required reviewer
    - Approver dans GitHub Actions UI
    - Output : approval enregistre

[8] Deploy prod execute (acadenice-devops via deploy-prod.yml)
    - SSH prod host
    - git checkout vX.Y.Z
    - docker compose -f compose.yml -f compose.prod.yml pull
    - docker compose -f compose.yml -f compose.prod.yml up -d
    - Healthcheck post-deploy
    - Output : prod deploye

[9] Smoke tests prod (acadenice-devops + script)
    - Run scripts/smoke-test.sh contre PROD_URL
    - Verifier 3 endpoints critiques
    - Output : smoke OK / KO

[10] Watch period (Corentin + acadenice-devops, 30 min)
     - Surveiller logs containers : docker compose logs -f --tail=200
     - Surveiller monitoring : UptimeRobot + (Phase 3+) Prometheus/Grafana
     - Surveiller saisies utilisateur : pas de chute brutale ?
     - Output : 30 min vert ou alerte

[11] Annonce release (Corentin)
     - Slack/Teams interne : "Released vX.Y.Z. Highlights: ..."
     - Mettre a jour CHANGELOG.md commit dans release notes GitHub/Forgejo
     - Output : equipe informee

[12] Si tout OK : RELEASE COMPLETE
     - Notifier ops : new version live
     - Si KO : declencher WF rollback (cf incident.md)

Gates humains bloquants

Gate	Decision	Owner
Validation manuelle staging (4)	OK / RETOUR FIX	Corentin
Tag semver (6)	release ou abort	Corentin
Approval prod (7)	APPROVE / DENY	Yan ou Corentin (manual GitHub UI)
Watch period (10)	tout OK / rollback	Corentin

Rollback (en cas d'echec)

Cf doc 17 section 6 + workflow incident.md :

Scenario	Action
Healthcheck KO post-deploy	Re-deploy version precedente : git tag vX.Y.Z-rollback v<previous> && git push --tags → trigger deploy-prod.yml
Bug critique decouvert dans watch period	Idem rollback automatique vers version stable
Migration schema casse rollups	Restore Postgres backup pre-deploy + redeploy version stable
Compromission credentials post-deploy	Rotate secrets + redeploy + audit logs

Outputs

• Tag semver cree sur main
• Image Docker tagged + pushed registry
• Prod deployee + verifiee
• CHANGELOG release section publiee
• Notification equipe envoyee
• (Si rollback) post-mortem dans docs/post-mortems/YYYY-MM-DD-<title>.md

Convention semver (rappel)

Type	Quand	Exemple
MAJOR	Breaking change (migration data forcee, rupture API)	v1.x.x → v2.0.0
MINOR	Nouvelle feature backward-compatible	v1.2.x → v1.3.0
PATCH	Bug fix / security fix	v1.2.3 → v1.2.4

Frequence de release

• Phase 1 vanilla : release initiale v0.1.0 quand Phase 1 stable + utilisee 1 semaine
• Phase 2 bridge : releases v0.2.x → v0.9.x au fil des stories validees
• Phase 3 maturite : v1.0.0 quand bidirec backlinks + dual-mode editor + MCP server livres
• Phase 4+ : releases mensuelles minimum

Notes

• Pas de release vendredi soir (tradition tech : eviter d'avoir a fixer en weekend)
• Pas de release pendant fenetre maintenance Acadenice (cours en cours, etc.)
• Si urgent en prod : hotfix branch depuis tag stable, micro-release patch (ex: v1.2.4 → v1.2.5)