Oppgraderingspolicy

v1.2.x · oppdatert 2026-08-04

Stabilitet er et produktprinsipp, ikke en ettertanke. AiHummer følger SemVer, gjelder fremoversikre databaseoppgraderinger automatisk, og kan selvoppdatering fra en CDN — så oppgraderinger er rutinemessige fremfor risikable.

Versjonering (SemVer)

Utgivelser følger semantisk versjonering. Versjonen rapporteres av /healthz og ved aihummer version, slik at du alltid kan bekrefte nøyaktig hva som kjører før og etter en oppgradering.

Migrasjoner er fremtidstrygge og automatiske

Ved oppstart påfører gatewayen ventende databasemigrasjoner automatisk. To egenskaper holder dette trygt:

Fremoversikker. Migrasjoner er skrevet slik at en nyere binær fungerer mot skjemaet det migrerer til, som er det som gjør auto-apply og rullerende oppgraderinger trygge.
Enkelt-applikator via rådgivende lås. Migrasjoner kjøres under en PostgreSQL veiledende lås, så når flere gatewayer starter samtidig, gjelder bare én av dem og resten venter — aldri en dobbel migrasjon.

[!NOTE] Migrasjoner kjører alltid på eierdatabasesamlingen. Den begrensede RLS-rollen (AIHUMMER_DB_APP_URL) er for å håndtere trafikk, ikke for skjemaendringer.

Oppdatering

Nye versjoner hentes fra leverandørens release-CDN. Måten som støttes, er én enkelt kommando på serveren:

aihummer update --check   # only report whether a newer version exists
aihummer update           # download and apply it

--check skriver ingenting og trenger derfor ikke root. Å faktisk ta i bruk en oppdatering skriver om installasjonsroten og starter tjenesten på nytt, så den kjøringen gjøres med sudo.

Forventet resultat: --check skriver ut gjeldende og tilgjengelig versjon og avslutter uten å endre noe. aihummer update henter artefakten, kontrollerer sha256-summen og cosign-signaturen, bytter binærfilen og starter tjenesten på nytt — deretter viser aihummer version den nye versjonen. Stemmer kontrollen ikke, avbrytes oppdateringen før byttet: versjonen som kjører, blir liggende urørt.

[!NOTE] Automatisk oppdatering slås på av leverandøren, ikke av deg. Modus og tidsplan for automatisk oppdatering hører til vedlikeholdet av utgivelsen og settes gjennom et signert direktiv fra leverandøren. Brytere for dette finnes verken i nettgrensesnittet eller i aihummer settings, og variabler for automatisk oppdatering som er skrevet inn i gateway.env, leses ikke av gatewayen — ser du dem der, har de ingen virkning. Vil du oppdatere etter din egen plan, bruker du kommandoen aihummer update ovenfor.

Tilbakerulling

Hva som lar seg rulle tilbake, punkt for punkt:

Binærfilen — kan settes tilbake til forrige versjon (artefakter fra tidligere utgivelser blir liggende på CDN-en; installer på nytt den versjonen du vil ha).
Databaseskjemaet — migrasjonene er fremoversikre, så den forrige binærfilen fungerer mot det nyere skjemaet; noen egen tilbakerulling av skjemaet trengs ikke.
Utvidelser — versjonene styres per installasjon; rull en utvidelse tilbake fra katalogen om du trenger det.
Konfigurasjonen — røres ikke av en oppdatering; gjenopprett den fra en sikkerhetskopi ved behov.

utrullinger med null nedetid

AiHummer er bygd for å oppgradere uten nedetid:

Kjør 2+ gatewayer bak en proxy. Rull dem en om gangen; beredskapsprøven (/readyz) holder en omstartende node ute av rotasjon til den er i tjeneste.
Planleggeren er enkeltleder. Bakgrunnsplanlegging velger en enkelt leder via en PostgreSQL rådgivningslås, slik at kjøring av flere gateways ikke dobler planlagt arbeid.
Levering er idempotent. Pålitelige leveranser pluss idempotensnøkler betyr en svar sendes aldri to ganger over en omstart, noe som gjør en rullende start på nytt trygt på tvers av gatewayene dine.

Hvor til neste

Prober som styrer en rullerende omstart: systemd og helsesjekker.
Sikkerhetskopier før en større oppgradering: Sikkerhetskopier og katastrofegjenoppretting.
Se utrullingen: Observerbarhet.