Mettre à jour une instance

Cette fiche décrit comment faire évoluer une instance TimePick déjà installée (Docker ou Coolify) vers une nouvelle version du code, et comment vérifier que la mise à jour s'est bien déroulée.

Avant de mettre à jour

Sauvegardez la base avant toute mise à jour

Une mise à jour applique de nouvelles migrations de base de données. Effectuez une sauvegarde avant de lancer la procédure — voir Sauvegarde et restauration.

Workflow nominal

Le principe est le même quel que soit l'hébergement : mettre à jour le code source, puis reconstruire et redémarrer le conteneur. Les migrations de base de données s'appliquent alors automatiquement, sans action manuelle.

Avec Coolify

1. Le code de la nouvelle version est poussé sur la branche suivie par Coolify (main dans la configuration type).
2. Dans Coolify → application TimePick, cliquer Redeploy.

git push origin main

Redéploiement automatique

Une fois qu'un premier déploiement a réussi, Coolify peut redéployer automatiquement à chaque git push grâce au webhook GitHub configuré à l'installation. Tant que ce webhook n'est pas actif, le clic manuel sur Redeploy reste nécessaire.

Sans Coolify (Docker manuel)

1. Récupérer la nouvelle version du code sur le serveur.
2. Reconstruire l'image et redémarrer le conteneur (l'image Docker embarque le client et le serveur).

Ce qui se passe automatiquement au démarrage

À chaque démarrage d'un conteneur (premier déploiement comme redéploiement), la même séquence s'exécute avant que le serveur n'accepte des connexions :

1. Bootstrap (prepare-db) — vérifie et prépare la base si nécessaire ; idempotent, sans effet si la base est déjà initialisée.
2. Migrations (migrate) — applique uniquement les migrations qui n'ont pas encore été jouées sur cette base.
3. Le serveur commence à écouter une fois ces deux étapes terminées.

Il n'y a rien à déclencher manuellement : les migrations font partie du démarrage du conteneur.

Le volume des fichiers uploadés (images d'emails) est conservé d'un déploiement à l'autre — il n'est pas régénéré.

Politique des migrations : forward-only, sans rollback

TimePick applique une politique de migrations append-only et forward-only : chaque migration ajoute un changement de schéma de façon irréversible, et il n'existe aucun script de rollback automatique fourni pour revenir en arrière.

En pratique, pour un opérateur :

• Une mise à jour n'a pas de bouton « annuler » côté base de données. Si une migration pose problème après application, on ne peut pas simplement « redescendre » d'une version.
• La seule voie de retour arrière consiste à revenir en arrière côté code (annuler le déploiement de la nouvelle version) et, si le schéma a déjà changé, à corriger la base manuellement avec une requête SQL adaptée, ou à restaurer une sauvegarde antérieure à la mise à jour.
• C'est pourquoi la sauvegarde préalable (voir plus haut) n'est pas optionnelle : c'est le principal filet de sécurité en cas de mise à jour problématique.

Ne jamais éditer une migration déjà appliquée

Une migration déjà exécutée sur une base ne doit jamais être modifiée après coup, y compris pour corriger une erreur. Toute correction doit passer par une nouvelle migration. Modifier un fichier déjà appliqué désynchronise les instances qui l'ont déjà joué de celles qui ne l'ont pas encore fait.

Vérifier après une mise à jour

Trois vérifications rapides suffisent à confirmer qu'une mise à jour s'est bien déroulée :

1. Le healthcheck répond :

curl -I https://votre-domaine.tld/health

Doit renvoyer un code 200.

2. La version affichée a changé — dans l'interface, le numéro de version apparaît en bas de la barre latérale (sous le profil utilisateur). Comparer avec la version attendue.

3. Les logs du conteneur au démarrage — vérifier la présence des lignes de bootstrap et de migration (préfixées [prepare-db] puis [migrate]) suivies du message indiquant que le serveur écoute. Leur absence, ou une interruption avant ces lignes, signale un échec de démarrage.

En cas d'échec au démarrage

Si le conteneur ne devient pas « en bonne santé » après une mise à jour :

• Consulter les logs du conteneur en priorité : une migration en erreur, ou un problème de connexion à la base, empêche le serveur de démarrer et s'arrête volontairement plutôt que de tourner dans un état incohérent.
• Vérifier qu'aucune variable d'environnement requise n'a été retirée par erreur.
• Pour le dépannage détaillé, voir Dépannage.