D'un commit à la prod

Cette page suit un changement du backend, de la pull request jusqu'à la production, sans aucune action manuelle après le merge.

L'histoire complète

Étape par étape

1. Le merge

Un développeur fusionne une pull request dans main. Il n'y a rien d'autre à faire.

2. La détection (jusqu'à 2 min)

Tout ce qui suit se suit en direct dans Jenkins : pipeline backend, pipeline frontend. Voir Accéder aux pipelines.

Le job TimeManager/backend interroge GitHub toutes les 2 minutes. Il voit un nouveau commit qui touche timemanager-api/ : il lance le pipeline. Si le commit ne touchait que timemanager-web/, ce serait le job frontend. S'il ne touchait que le mobile, aucun.

3. Les tests

Une base PostgreSQL jetable est lancée, mix test tourne contre elle, puis tout est supprimé. Si un test échoue : le build s'arrête, rien n'est déployé, et Jenkins affiche le build en rouge.

4. Le build

L'image finale est construite et étiquetée avec le hash du commit.

5. Le scan

Trivy cherche les failles connues. Une faille critique arrête tout.

6. Le push

L'image part sur GHCR sous deux noms : :cece380 (pour toujours) et :latest (qui bouge à chaque build).

7. Le déploiement

Jenkins se connecte à tm-prod en deploy, par le réseau privé, et lance :

cd /opt/timemanager/app
docker compose pull back
docker compose up -d back
docker image prune -af

Docker Compose voit que l'image de back a changé : il arrête l'ancien conteneur et en démarre un nouveau. La base db et le site front ne sont pas touchés.

8. Le démarrage

Le nouveau conteneur exécute entrypoint.sh : les migrations d'abord, puis le serveur. Traefik envoie les requêtes à timemanager-back:4000, qui est maintenant le nouveau conteneur.

Une courte coupure

Entre l'arrêt de l'ancien conteneur et le démarrage complet du nouveau, l'API ne répond pas pendant quelques secondes. Les clients voient une erreur 502 de Traefik, puis tout revient.

Et pour le frontend ?

Pareil, avec ces différences :

• pas d'étape de test ;
• le build reçoit VITE_API_URL ;
• le déploiement fait pull front et up -d front.

Et pour la documentation ?

Pareil que le frontend : pas de test, une image nginx, pull docs et up -d docs. L'image est construite depuis la racine du dépôt pour inclure docs/database.mmd. Voir Le pipeline documentation.

Et pour le mobile ?

L'app mobile n'est pas déployée par Jenkins. Elle est lancée avec Expo Go en développement. Une publication sur les stores passerait par EAS Build d'Expo (voir Limites et améliorations).

Et pour l'infrastructure ?

Un changement dans timemanager-devops/ansible/, traefik/ ou app/docker-compose.yml n'est pas appliqué par Jenkins. Il faut lancer Ansible depuis son ordinateur :

Changement	Commande
Une route Traefik	ansible-playbook playbook.yml --tags traefik --ask-vault-pass
app/docker-compose.yml ou un secret de l'app	ansible-playbook playbook.yml --tags app --ask-vault-pass
Jenkins (casc, plugins, jobs)	ansible-playbook playbook.yml --tags jenkins --ask-vault-pass
Le pare-feu	ansible-playbook playbook.yml --tags ufw --ask-vault-pass

Préparer une machine neuve

Tout reconstruire depuis zéro (création des VM, pare-feu, IP statiques, Ansible, premier administrateur) est décrit pas à pas dans Mise en place.

La base de données

Une machine neuve a une base vide. Les données de l'ancienne ne sont pas recréées par Ansible. Voir Limites et améliorations.