Mise à jour

1. Avant de commencerCopier le lien du titre

1. Vérifiez et construisez le nouveau kit comme pour l’installation. Notez le nom d’image affiché : NOUVELLE_IMAGE ci-dessous.

2. Attendez la fin des calculs en cours et suspendez les nouvelles modifications.

3. Vérifiez que le Python de la machine dispose des paquets de backend/requirements.txt : le lanceur fait une sauvegarde avant toute modification.

4. Si un outil du serveur supprime les images Docker inutilisées, comme le nettoyage Docker de Coolify, sauvegardez d’abord l’image actuelle, par exemple docker save -o CHEMIN_PRIVE/backups/IMAGE_ACTUELLE.tar IMAGE_ACTUELLE : après la mise à jour elle n’est plus utilisée, et elle sert à revenir en arrière. docker load -i la restaure.

5. Lisez les changements de schéma que la nouvelle version apporte : certains demandent une action dans l’application après la mise à jour.

Ne supprimez jamais les volumes et ne relancez pas la première configuration pour mettre à jour. Modifier uniquement --image ne met pas à jour une installation existante : l’image est enregistrée dans son dossier privé.

2. Mettre à jour une installation créée par le lanceurCopier le lien du titre

Depuis le kit de la version actuellement installée (la sauvegarde effectuée vérifie le schéma par rapport à ce kit) :

python3 scripts/start_server.py --directory CHEMIN_PRIVE --upgrade-image NOUVELLE_IMAGE

Une installation locale utilise python scripts/start_local.py --directory CHEMIN_PRIVE --upgrade-image NOUVELLE_IMAGE.

Le lanceur, dans l’ordre :

1. vérifie que la nouvelle image existe et diffère de l’image actuelle ;
2. écrit une sauvegarde dans CHEMIN_PRIVE/backups/before-upgrade-<heure UTC>.dump ; si elle échoue, rien n’est modifié ;
3. arrête l’API et le worker ;
4. enregistre la nouvelle image, et la précédente, dans image.json et workspace.json ;
5. démarre l’installation : setup exécute les migrations de la base avant le démarrage de l’API et du worker.

Sur un VPS de 2 vCPU et 8 Go partagé avec Coolify, cela a pris 19 s, sauvegarde comprise ; voir Installer sur un VPS, pas à pas. Utilisez ensuite le kit de la nouvelle version pour la maintenance. Les démarrages suivants d’une installation serveur indiquent la nouvelle image avec --image ; le lanceur refuse des valeurs différentes de celles de l’installation enregistrée.

3. Si la mise à jour ne démarre pasCopier le lien du titre

Le lanceur affiche : « Upgrade did not start. If setup failed, API and worker stay stopped and the database is preserved. » Il indique aussi l’image précédente.

Conservez cette base pour diagnostic. Ne réinitialisez pas le volume et ne démarrez pas l’image précédente sur la base migrée : une ancienne image n’est pas forcément compatible avec un schéma plus récent.

4. Revenir à la version précédenteCopier le lien du titre

Il n’existe pas de commande de retour arrière en une étape. Avec le kit de la version précédente :

1. Restaurez la sauvegarde before-upgrade dans une base isolée, comme dans Sauvegarde et restauration.
2. Démarrez l’image précédente enregistrée (previous_image dans workspace.json) sur cette copie.
3. Vérifiez connexion, données et calcul avant de rouvrir l’accès.

5. Mettre à jour une installation Compose sans le lanceurCopier le lien du titre

Pour une installation configurée dans .env, en répétant les surcouches qu’elle utilise sur chaque commande Compose qui modifie les services :

python scripts/database_backup.py backup
docker compose --env-file .env -f deploy/docker-compose.example.yml stop api worker
docker compose --env-file .env -f deploy/docker-compose.example.yml up --build -d

Faites la sauvegarde avec le kit de la version installée. Si setup échoue, laissez l’API et le worker arrêtés et corrigez le problème de configuration ou de schéma signalé avant de réessayer.

Une installation issue d’une version antérieure qui utilisait le compte d’administration initial de la base demande d’abord une sauvegarde PostgreSQL de confiance faite avec ce compte, puis les identifiants distincts d’exécution et de migration de la référence de configuration.

6. Fonctionnement des migrationsCopier le lien du titre

Le service setup exécute python -m app.setup_database avec la même image que l’API. Il prépare les rôles gérés de la base, exécute les migrations avec le rôle propriétaire et accorde ses droits au rôle d’exécution. L’API attend la réussite de setup ; son démarrage normal n’exécute jamais de migration et n’insère aucune donnée.

Les migrations conservent les identifiants et les modifications existants, mais certaines transforment des données, comme 0012_weekly_hours. Leur retour arrière n’est pas une procédure de rétablissement : revenez en arrière en restaurant une sauvegarde, comme à l’étape 4.

7. Vérifier l’installation mise à jourCopier le lien du titre

1. docker compose ps indique une API, un worker et une base sains ; GET /api/v1/ready répond.
2. Un compte nominatif se connecte et conserve sa langue.
3. Le dépôt, les véhicules, les livraisons et les plans enregistrés sont présents.
4. Planification n’affiche pas le bandeau Le service de calcul nécessite une intervention.
5. Un calcul représentatif produit un résultat vérifiable.
6. Les actions demandées par les nouvelles migrations, décrites ci-dessous, sont faites.

Ne rouvrez l’accès qu’après ces vérifications.

8. Migrations 0009 à 0017Copier le lien du titre

Une installation antérieure reçoit toutes ces migrations lors de la mise à jour : setup les applique dans l’ordre, sans commande supplémentaire. Cette version attend la révision de schéma 0017_safety_margin ; GET /api/v1/ready et la commande de sauvegarde la vérifient.

Les trois fonctions appartiennent au rôle de migration ; setup accorde au rôle d’exécution le seul droit de les exécuter.

Après la mise à jour :

1. Horaires des véhicules. Après 0012_weekly_hours, un véhicule d’entreprise ne travaille que le jour de son ancienne fenêtre : un calcul d’un autre jour le refuse (VEHICLE_OFF_DAY). Renseignez une fois la semaine de chaque véhicule dans Flotte, ou réimportez le fichier des véhicules avec les nouvelles colonnes.
2. Ancien espace d’exemple. Après 0016_examples, l’entreprise garde le dépôt fictif de Paris comme dépôt principal. Avant de planifier de vraies livraisons, remplacez son adresse et son entrée par celles de votre dépôt, ajoutez vos véhicules, puis retirez les exemples dans Paramètres → Données d’exemple.
3. Intégrations. Le fichier CSV des véhicules remplace available_start,available_end par une colonne par jour (monday … sunday, par exemple 07:30-17:00, vide pour un jour non travaillé). POST /api/v1/vehicles/availability et POST /api/v1/workspace/company n’existent plus ; POST /api/v1/setup refuse workspace_kind et exige depot. Voir la référence API.
4. Marge de sécurité. Après 0017_safety_margin, les nouveaux calculs prévoient le début de chaque livraison au moins 15 minutes avant la fin de son créneau, là où ils planifiaient jusqu’à sa dernière minute. Une livraison qui ne peut être atteinte que dans ces dernières minutes peut désormais rester non affectée. Un administrateur modifie la marge dans Paramètres → Calcul (0 planifie jusqu’à la fin du créneau). Les plans calculés avant la mise à jour indiquent leur marge comme Aucune : planifié jusqu’à la dernière minute.

Les retours arrière de 0015_depots et 0016_examples refusent de s’exécuter tant que d’autres dépôts ou lieux, ou des exemples, existent ; celui de 0012_weekly_hours ne rétablit qu’une fenêtre par véhicule. Pour revenir à la version précédente, restaurez la sauvegarde before-upgrade, comme à l’étape 4.