Upgrade vs. Update

Semantic Versioning (SemVer): MAJOR.MINOR.PATCH (z. B. 2.4.1)

• Patch (1): Update. Gefahrlos installierbar.
• Minor (4): Feature-Update. Neue Funktionen, aber abwärtskompatibel.
• Major (2): Upgrade. Achtung! Breaking Changes. Dein Code könnte kaputt gehen.

Strategie:

• Updates: Automatisch installieren (für Sicherheit).
• Upgrades: Planen, testen, manuell durchführen.

1. In-Place vs. Immutable Upgrade

• In-Place: Du loggst dich auf dem Server ein und führst apt-get dist-upgrade aus.
  • Risiko: Wenn es schiefgeht, ist der Server "halbtot". Rollback ist schwer.
• Immutable (Blue/Green): Du fasst den alten Server (Blue) gar nicht an. Du startest einen neuen Server (Green) mit der neuen Version. Wenn Green läuft, schwenkst du den Traffic um. Wenn Green crasht, schwenkst du zurück auf Blue. (Standard in Kubernetes).

2. Database Upgrades

Die Königsdisziplin. Code ist stateless (einfach austauschen). Daten sind stateful (schwer). Ein Postgres Major Upgrade ändert das Festplatten-Format. Strategien:

• Dump & Restore: Alles exportieren, DB löschen, neu installieren, importieren. (Dauert Stunden -> Downtime).
• pg_upgrade: Nutzt Hardlinks, um Dateien in Sekunden zu konvertieren. (Schnell).
• Logical Replication: Neue DB liest live Daten von alter DB. Umschalten mit fast 0 Downtime.

3. Canary Upgrade

Du installierst das Upgrade erst bei 1% der Nutzer (Kanarienvogel). Wenn keine Fehler auftreten -> 10% -> 50% -> 100%. Wenn Fehler -> Sofort Stopp für die anderen 99%.

1. Datenbank-Migrationen (Flyway/Liquibase)

Upgrades betreffen oft das Tabellenschema. "Wir brauchen eine neue Spalte 'email_verified' in der User-Tabelle." Statt das manuell einzutippen, nutzt man Migrations-Skripte. Diese Skripte (V1__add_email_col.sql) sind versionskontrolliert. Wenn die App startet, prüft sie: "Welche Version hat die DB? V1? Ok, ich führe das Skript für V2 aus." So wird sichergestellt, dass jede Instanz (Dev, Prod) exakt den gleichen Datenbank-Stand hat. Ein fehlgeschlagenes Migrations-Script ist der häufigste Grund für scheiternde Cloud-Upgrades.

2. Dual-Write Phase (Zero Downtime)

Wenn man ein Feld in der Datenbank umbenennen will (von user_name zu login_name), kann man nicht einfach upgraden, da der alte Code das alte Feld und der neue Code das neue Feld erwartet. Man nutzt einen 3-Schritte-Plan:

1. Dual Write: Neuer Code schreibt in beide Felder. Liest aber noch vom alten.
2. Backfill: Man kopiert alle alten Daten in das neue Feld.
3. Switchover: Neuer Code liest und schreibt nur noch ins neue Feld. Das alte Feld wird in einem späteren Patch gelöscht. Dies ist der professionelle Weg für Upgrades ohne eine einzige Sekunde Wartungsfenster.

3. Pre-Releases und Build Metadata

SemVer erlaubt Anhänge: 1.0.0-alpha.1 oder 1.0.0+build.2023.

• Ein Pre-Release wird als "niedriger" als die echte Version gewertet (1.0.0-rc1 < 1.0.0).
• Build Metadata wird beim Versionsvergleich ignoriert. Das ist wichtig für automatisierte Systeme: Sie dürfen eine "Alpha" Version niemals automatisch als Upgrade für ein stabiles System installieren, selbst wenn die Nummern danach höher aussehen.