Updates & Upgrades

Diese Seite beschreibt das Vorgehen bei einem Update. Die vollständigen Änderungen und Installationshinweise je Release stehen in der Versionshistorie.

Vorgehen bei einem Update

Die Konfiguration in Table Storage bleibt bei einem Update unverändert — es sei denn, ein Breaking Change erfordert Anpassungen.

Schritte

1. Release Notes prüfen — Breaking Changes und Installationshinweise des Zielrelease und aller dazwischenliegenden Versionen lesen (Versionshistorie)
2. Wartungsfenster einplanen — GetChanges über ein App-Setting deaktivieren:

   AzureWebJobs.GetChanges.Disabled = true
   

   Bei Bedarf lassen sich die Verarbeiter analog abschalten (AzureWebJobs.ProcessStandardQueueItems.Disabled usw.)
3. Warten, bis alle Queue-Nachrichten verarbeitet wurden (Queue-Länge im Azure Portal prüfen)
4. Neue Version einspielen — je nach Betriebsart:
   • Container: Image-Tag auf die neue Version setzen
   • Marketplace: Assistenten erneut durchlaufen (bei unveränderten Standardwerten ergibt sich keine Änderung an bestehenden Einstellungen)
   • Bicep / Pipeline: Deployment erneut ausführen
   • Zip-Upload: Paket über die Pipeline oder manuell einspielen
5. Konfigurationsanpassungen aus den Installationshinweisen vornehmen
6. GetChanges wieder aktivieren:

   AzureWebJobs.GetChanges.Disabled = false (oder Eintrag löschen)
   

7. Ersten Lauf beobachten — z. B. über die Custom Metric ChangesDetected je Job oder die Fehlerquoten-Abfrage unter Performance & Laufzeiten

Breaking Changes je Version

Die vollständigen Breaking Changes und Installationshinweise stehen ausschließlich in den Release Notes der jeweiligen Version — hier nur der Überblick, ob ein Übergang überhaupt einen Breaking Change enthält:

Beim Überspringen von Versionen sind die Release Notes aller dazwischenliegenden Versionen zu beachten, nicht nur die des Zielrelease.