Politique de mise à niveau

v1.2.x · mis à jour 2026-08-04

La stabilité est un principe de produit, pas une idée après coup. AiHummer suit SemVer, s’applique migrations de base de données sûres vers l’avant automatiquement, et peut auto-mise à jour à partir d’un CDN — donc les mises à jour sont courantes plutôt que risquées.

Gestion des versions (SemVer)

Les versions suivent le versionnage sémantique. La version est indiquée par /healthz et par aihummer version, afin que vous puissiez toujours confirmer exactement ce qui fonctionne avant et après une mise à jour.

Les migrations sont sûres pour l’avenir et automatiques

Au démarrage, la passerelle applique automatiquement les migrations de base de données en attente. Deux propriétés garantissent cette sécurité :

Sûr vers l’avant. Les migrations sont écrites de manière à ce qu’un binaire plus récent fonctionne avec le schéma vers lequel il migre, ce qui rend l’application automatique et les mises à niveau progressives sûres.
Appliquant unique via verrou consultatif. Les migrations s’exécutent sous un PostgreSQL verrou consultatif, donc lorsque plusieurs passerelles démarrent en même temps, une seule les applique et le reste attend — jamais une double migration.

[!NOTE] Les migrations s’exécutent toujours sur le pool de bases de données propriétaire. Le rôle RLS restreint (AIHUMMER_DB_APP_URL) est destiné à gérer le trafic, pas aux modifications de schéma.

Mise à jour

Les nouvelles versions sont récupérées depuis le CDN de publication du fournisseur. La manière prise en charge de se mettre à jour tient en une seule commande sur le serveur :

aihummer update --check   # report whether a newer version is available
aihummer update           # download and apply the update

--check n’écrit rien et ne demande donc pas les droits root. Appliquer une mise à jour réécrit la racine d’installation et redémarre le service : lancez-la avec sudo.

Résultat attendu : --check affiche la version courante et la version disponible, puis se termine sans rien modifier. aihummer update télécharge l’artefact, vérifie sa somme de contrôle sha256 et sa signature cosign, remplace le binaire et redémarre le service ; ensuite aihummer version annonce la nouvelle version. Si la vérification échoue, la mise à jour est interrompue avant le remplacement : la version en cours d’exécution reste intacte.

[!NOTE] La mise à jour automatique est activée par le fournisseur, pas par vous. Son mode et sa périodicité font partie du maintien en condition de la version et sont fixés par une directive signée du fournisseur. Aucun réglage correspondant n’existe dans l’interface web ni dans aihummer settings, et les variables d’auto-mise à jour inscrites dans gateway.env ne sont pas lues par la passerelle : si vous les y voyez, elles n’ont aucun effet. Pour vous mettre à jour à votre propre rythme, utilisez la commande aihummer update ci-dessus.

Retour arrière

Ce qui peut être ramené en arrière, élément par élément :

Binaire — il peut revenir à la version précédente (les artefacts des versions antérieures restent sur le CDN ; réinstallez celle que vous souhaitez).
Schéma de base de données — les migrations sont sûres vers l’avant, donc le binaire précédent fonctionne avec le schéma plus récent ; il n’existe pas de retour arrière de schéma distinct.
Plugins — les versions se gèrent par installation ; au besoin, ramenez un plugin à sa version antérieure depuis le catalogue.
Configuration — une mise à jour n’y touche pas ; restaurez-la depuis une sauvegarde si nécessaire.

Déploiements sans interruption

AiHummer est conçu pour être mis à niveau sans interruption :

Exécutez 2+ passerelles derrière un proxy. Roulez-les un à la fois ; la sonde de disponibilité (/readyz) empêche un nœud en redémarrage de reprendre sa rotation jusqu’à ce qu’il soit opérationnel.
Le planificateur est à leader unique. La planification en arrière-plan élit un leader unique via un verrou consultatif PostgreSQL, donc exécuter plusieurs passerelles ne duplique pas travail prévu.
La livraison est idempotente. Une livraison fiable ainsi que des clés d’idempotence signifient un la réponse n’est jamais envoyée deux fois après un redémarrage, ce qui fait qu’un défilement redémarrez en toute sécurité à travers vos passerelles.

Où aller ensuite

Sondes qui contrôlent un redémarrage progressif : systemd et contrôles de santé.
Sauvegardez avant une mise à niveau majeure : Sauvegardes et reprise après sinistre.
Regardez le déploiement : Observabilité.