Mettre à jour gitrust
À qui s'adresse cette page
Administrateurs qui souhaitent appliquer une nouvelle version de gitrust sur une instance en production, en limitant les risques.
Principe général
Les migrations de base de données sont appliquées automatiquement au démarrage par AppMigrator. Vous n'avez jamais à exécuter de commande SQL manuellement. Le binaire contient toujours les migrations cumulatives.
flowchart LR
A[Sauvegarde] --> B[Arrêt service]
B --> C[Déploiement<br/>nouveau binaire]
C --> D[Démarrage]
D --> E{Migrations<br/>auto ?}
E -->|OK| F[Smoke test]
E -->|Erreur| G[Rollback]
F -->|OK| H[Terminé]
F -->|Erreur| G
Checklist de mise à jour
1. Sauvegarder avant tout
# Sauvegarde complète avant toute modification /opt/gitrust/scripts/backup.sh
Vérifiez que le dump PostgreSQL a été créé :
ls -lh /var/backups/gitrust/pg-$(date +%Y%m%d)*.dump
Ne passez à l'étape 2 que si la sauvegarde est confirmée.
2. Arrêter le service
# Systemd sudo systemctl stop gitrust # Docker Compose docker compose stop gitrust
Attendez la confirmation :
sudo systemctl is-active gitrust # Attendu : inactive
3. Déployer le nouveau binaire
Option A — via deploy.sh (recommandé si vous compilez localement) :
# Sur la machine de développement, depuis la racine du dépôt gitrust ./deployment/deploy.sh user@VOTRE_SERVEUR /opt/gitrust
Le script compile en release, synchronise le binaire, les assets statiques et le service systemd, puis redémarre automatiquement.
Option B — manuellement :
# Compiler le nouveau binaire cargo build --release # Compiler le CSS si les templates ont changé npx tailwindcss -i static/css/input.css -o static/css/style.css --minify # Transférer rsync -avz target/release/gitrust user@VOTRE_SERVEUR:/opt/gitrust/gitrust rsync -avz static/ user@VOTRE_SERVEUR:/opt/gitrust/static/ # Sur le serveur sudo chown gitrust:gitrust /opt/gitrust/gitrust sudo chmod 750 /opt/gitrust/gitrust
4. Vérifier les éventuels changements de .env
Consultez le CHANGELOG de la nouvelle version pour identifier les nouvelles variables d'environnement. Ajoutez-les à /opt/gitrust/.env si nécessaire, avec des valeurs appropriées.
# Comparer votre .env avec .env.example de la nouvelle version diff /opt/gitrust/.env .env.example | grep "^>"
5. Démarrer le service
# Systemd sudo systemctl start gitrust # Docker Compose docker compose up -d gitrust
6. Vérifier les migrations automatiques
sudo journalctl -u gitrust --since "2 minutes ago" --no-pager | grep -E "migrat|error|panic"
Sortie attendue si de nouvelles migrations ont été appliquées :
INFO gitrust_core::migrations: Applied migration m20260501_000014_add_webhooks INFO gitrust_core::migrations: All migrations applied successfully
Sortie attendue si aucune nouvelle migration :
INFO gitrust_core::migrations: No pending migrations
Si vous voyez ERROR ou panic, consultez la section Rollback.
7. Smoke test
# HTTP curl -s -o /dev/null -w "%{http_code}" http://localhost:4000/ # Attendu : 302 # SSH (fingerprint inchangé — comparer avec la valeur notée) ssh-keyscan -p 2222 -H localhost 2>/dev/null | ssh-keygen -l -f -
Connectez-vous à l'interface /admin et vérifiez :
- La liste des utilisateurs est correcte
- Un dépôt existant est accessible
- La page
/admin/settingss'affiche sans erreur
Rollback
Si le démarrage échoue ou si le smoke test révèle une régression :
1. Arrêter le service
sudo systemctl stop gitrust
2. Restaurer le binaire précédent
Si vous avez conservé l'ancien binaire (bonne pratique : le renommer avant la mise à jour) :
sudo cp /opt/gitrust/gitrust.backup /opt/gitrust/gitrust sudo chown gitrust:gitrust /opt/gitrust/gitrust
3. Restaurer la base de données si des migrations ont été appliquées
# Identifier la dernière sauvegarde pré-mise-à-jour DUMP=$(ls -t /var/backups/gitrust/pg-*.dump | head -1) echo "Restauration depuis : $DUMP" sudo -u postgres psql -c "DROP DATABASE IF EXISTS gitrust;" sudo -u postgres psql -c "CREATE DATABASE gitrust OWNER gitrust;" pg_restore -h localhost -U gitrust --dbname=gitrust "$DUMP"
4. Redémarrer avec l'ancienne version
sudo systemctl start gitrust
Attention : si des nouvelles migrations ont créé ou modifié des tables, le rollback de la base est indispensable avant de démarrer l'ancienne version. Un binaire ancien sur une base migratée peut produire des erreurs imprévisibles.
Conseils
- Conservez toujours le binaire précédent pendant 24 h avant de le supprimer (
mv gitrust gitrust.backup). - Planifiez les mises à jour en dehors des heures de pointe (le service est arrêté pendant l'opération).
- Les migrations sont idempotentes : redémarrer deux fois de suite avec la même version est sans risque.
GitRust