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
nouveau binaire]
    C --> D[Démarrage]
    D --> E{Migrations
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/settings s'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.

Pour aller plus loin