Mise à jour

Workflow de branches (trunk-based)

master est toujours déployable — chaque push dessus part en prod automatiquement (voir plus bas). Donc on ne travaille jamais directement sur master :

1. Nouvelle fonctionnalité/fix → une branche courte (feat/nom-de-la-feature, fix/nom-du-bug) depuis master.
2. On développe et teste dessus (la CI tourne sur toutes les branches et les PR — tests + lint + build frontend — sans jamais déployer).
3. Une fois prêt et testé (localement, y compris en navigateur pour le frontend) → merge dans master (via PR ou fast-forward local). Ce merge déclenche le déploiement automatique.
4. Supprimer la branche de feature une fois mergée.

Pas de branche dev permanente à maintenir à jour : chaque branche de feature est éphémère, et master reste la seule référence de "ce qui tourne en prod".

Flux normal (automatique)

1. git push sur master (typiquement via le merge d'une branche de feature, voir ci-dessus).
2. Le pipeline Forgejo Actions (.forgejo/workflows/ci-cd.yml) lance :
   • job test : pytest (avec Postgres/Redis de test) + build/lint du frontend.
   • job deploy (seulement si test passe, et seulement sur push master) : SSH vers tamagotchi@10.1.21.13, ce qui déclenche deploy/deploy.sh via une clé à commande forcée (le CI ne peut rien faire d'autre que lancer ce script précis).
3. deploy.sh fait : git pull → docker compose build → docker compose up -d (les migrations Alembic tournent automatiquement dans l'entrypoint du conteneur backend avant qu'il ne démarre) → nettoyage des vieilles images.

Rien à faire manuellement dans le cas normal.

Déploiement manuel (si besoin de forcer, ou CI indisponible)

ssh ansible@10.1.21.13
sudo -u tamagotchi bash -c 'cd /opt/tamagotchi/app && ./deploy/deploy.sh master'

(ou lancer le playbook Ansible complet depuis un poste de dev — voir Déploiement — si le provisioning a aussi changé, pas seulement le code applicatif)

Rollback

ssh ansible@10.1.21.13
sudo -u tamagotchi bash -c 'cd /opt/tamagotchi/app && ./deploy/deploy.sh <commit-ou-tag-precedent>'

deploy.sh accepte n'importe quelle référence git en argument (par défaut master). Attention : si le rollback revient en arrière sur une migration Alembic (colonne/table ajoutée par une migration plus récente), il faudra une migration de retour en arrière manuelle — Alembic ne fait pas de downgrade automatique au déploiement.

Ajouter une dépendance / changer le schéma de base

• Backend : ajouter dans requirements.txt, générer une migration Alembic (alembic revision --autogenerate -m "..."), commit, push — la migration s'applique toute seule au prochain déploiement.
• Frontend : npm install <paquet> dans frontend/, commit package.json + package-lock.json.

Pas de registre d'images : chaque déploiement reconstruit les images directement sur le serveur (docker compose build). Simple à maintenir seul, mais signifie que le serveur télécharge/compile les dépendances à chaque déploiement — acceptable au volume actuel du projet. Passer à un registre d'images (construit par le CI, poussé, puis juste docker pull côté serveur) est une évolution possible si les déploiements deviennent trop lents ou trop fréquents.