g2/enervision

Watch

Fork 0

[infra] Déploiement continu : relance automatique des applications à chaque merge sur main #95

New issue

Closed

opened 2026-09-02 16:30:45 +00:00 by gabriel · 1 comment

gabriel commented

2026-09-02 16:30:45 +00:00

Member

Exigence couverte

ENF-09

Épreuve servie

EC03 · CI/CD et qualité

Ce qu'on veut obtenir

Qu'un merge sur main déclenche automatiquement ansible-playbook site.yml contre le serveur de la salle, avec repo_version pointé sur le commit fusionné, et relance les piles Compose déclarées dans app_stacks sans intervention manuelle. Le geste actuel (ansible-playbook site.yml --ask-vault-pass lancé à la main depuis un poste) doit rester possible en secours, mais ne plus être le chemin normal.

Critères d'acceptation

Une tâche Forgejo se déclenche uniquement sur push vers main (jamais sur les pull requests ni sur develop) et joue ansible-playbook site.yml avec repo_version réglé sur le SHA fusionné
Le coffre ansible-vault et la clé SSH vers le serveur sont lus depuis les secrets Forgejo — aucun mot de passe ni clé privée en clair dans le dépôt (ENF-12), et le job échoue explicitement si un secret manque
Après un merge sur main, les piles de app_stacks sont Up avec l'état attendu sans qu'on se connecte au serveur — vérifié par un docker compose ps distant dans le job
Un échec d'ansible-playbook fait échouer le job de façon visible dans Forgejo, jamais silencieusement
docs/runbooks/deploiement.md décrit le déclenchement automatique et ce qui reste manuel (amorçage bootstrap.yml, restauration)

Comment on le vérifie

tests/ci/test-deploiement-continu.sh, joué par tests/ci/test-deploiement-continu.sh — vérifie statiquement le workflow (déclencheur limité à push main, pas de secret en clair, repo_version non figé sur develop). Preuve complémentaire à joindre au ticket : un merge réel sur main avec le job vert et la capture du docker compose ps du serveur après coup.

Manuel d'exploitation à mettre à jour

docs/runbooks/deploiement.md (section « Déployer ») et, si un nouveau job apparaît, docs/runbooks/ci.md.

Risque et retour arrière

Un déploiement automatique peut écraser un état modifié à la main sur le serveur, ou s'arrêter à mi-chemin (docker compose up partiel sur une pile). Retour arrière : rejouer site.yml avec repo_version figé sur le commit précédent, ou reprise manuelle par SSH. La clé SSH confiée au runner est un accès de production sensible : à scoper au strict nécessaire (utilisateur deploy, pas de sudo), jamais loguée.

### Exigence couverte ENF-09 ### Épreuve servie EC03 · CI/CD et qualité ### Ce qu'on veut obtenir Qu'un merge sur `main` déclenche automatiquement `ansible-playbook site.yml` contre le serveur de la salle, avec `repo_version` pointé sur le commit fusionné, et relance les piles Compose déclarées dans `app_stacks` sans intervention manuelle. Le geste actuel (`ansible-playbook site.yml --ask-vault-pass` lancé à la main depuis un poste) doit rester possible en secours, mais ne plus être le chemin normal. ### Critères d'acceptation - [ ] Une tâche Forgejo se déclenche uniquement sur `push` vers `main` (jamais sur les pull requests ni sur `develop`) et joue `ansible-playbook site.yml` avec `repo_version` réglé sur le SHA fusionné - [ ] Le coffre `ansible-vault` et la clé SSH vers le serveur sont lus depuis les secrets Forgejo — aucun mot de passe ni clé privée en clair dans le dépôt (ENF-12), et le job échoue explicitement si un secret manque - [ ] Après un merge sur `main`, les piles de `app_stacks` sont `Up` avec l'état attendu sans qu'on se connecte au serveur — vérifié par un `docker compose ps` distant dans le job - [ ] Un échec d'`ansible-playbook` fait échouer le job de façon visible dans Forgejo, jamais silencieusement - [ ] `docs/runbooks/deploiement.md` décrit le déclenchement automatique et ce qui reste manuel (amorçage `bootstrap.yml`, restauration) ### Comment on le vérifie `tests/ci/test-deploiement-continu.sh`, joué par `tests/ci/test-deploiement-continu.sh` — vérifie statiquement le workflow (déclencheur limité à `push main`, pas de secret en clair, `repo_version` non figé sur `develop`). Preuve complémentaire à joindre au ticket : un merge réel sur `main` avec le job vert et la capture du `docker compose ps` du serveur après coup. ### Manuel d'exploitation à mettre à jour `docs/runbooks/deploiement.md` (section « Déployer ») et, si un nouveau job apparaît, `docs/runbooks/ci.md`. ### Risque et retour arrière Un déploiement automatique peut écraser un état modifié à la main sur le serveur, ou s'arrêter à mi-chemin (`docker compose up` partiel sur une pile). Retour arrière : rejouer `site.yml` avec `repo_version` figé sur le commit précédent, ou reprise manuelle par SSH. La clé SSH confiée au runner est un accès de production sensible : à scoper au strict nécessaire (utilisateur `deploy`, pas de sudo), jamais loguée.

gabriel added the

Kind/Infra

EC03

labels

2026-09-02 16:30:45 +00:00

gabriel self-assigned this

2026-09-02 16:34:36 +00:00

gabriel added the

Priority

Medium

label

2026-09-02 16:34:57 +00:00

gabriel added this to the EnerVision project

2026-09-02 16:35:00 +00:00

gabriel referenced this issue from a commit

2026-09-02 17:45:59 +00:00

infra: déploiement continu du rôle app à chaque merge sur main

gabriel referenced this issue from a commit

2026-09-02 17:45:59 +00:00

infra: fiabilise le déploiement continu (revue du ticket #95)

gabriel referenced this issue

2026-09-02 17:47:41 +00:00

infra: déploiement continu — relance automatique des apps à chaque merge sur main (#95) #96

lenaic referenced this issue from a commit

2026-09-02 19:28:27 +00:00

Merge pull request 'infra: déploiement continu — relance automatique des apps à chaque merge sur main (#95)' (#96) from gabriel/95-deploiement-continu into develop

lenaic added a new dependency

2026-09-03 11:19:27 +00:00

#113 [infra] Déploiement complet : MLflow, collecteur et migrations posés par le rôle Ansible

gabriel added the due date 2026-09-11

2026-09-03 12:41:08 +00:00

gabriel closed this issue

2026-09-03 13:49:13 +00:00

gabriel commented

2026-09-03 13:57:06 +00:00

Author

Member

Livré par la PR #96 (mergée dans develop) : la chaîne relance les applications à chaque merge. On ferme. Le déploiement continu sort de la liste « écarté de la fenêtre » du BACKLOG.

Livré par la PR #96 (mergée dans `develop`) : la chaîne relance les applications à chaque merge. On ferme. Le déploiement continu sort de la liste « écarté de la fenêtre » du BACKLOG.

gabriel referenced this issue from a commit

2026-09-04 08:09:51 +00:00

docs: réaligne PRD et BACKLOG sur l'état réel de la forge

gabriel referenced this issue from a commit

2026-09-04 08:10:54 +00:00

docs: réaligne PRD et BACKLOG sur l'état réel de la forge