Debuggen

Die DataBridge lokal mit Breakpoints debuggen — entweder gegen die Podman-Testumgebung oder gegen eine echte Azure-Instanz.
Themen:

Für Breakpoints und Step-Through läuft die DataBridge nicht im Container, sondern lokal als Prozess in der IDE. Zwei grundsätzlich verschiedene Varianten, je nachdem wogegen die lokal laufende DataBridge sprechen soll:

Gegen Podman debuggen

Azurite, Podman-Datenbanken, Service-Bus-Emulator, WireMock — alles lokal, keine Azure-Kosten, jederzeit zurücksetzbar.

→ Zum Artikel

Gegen echtes Azure debuggen

Echter Storage Account, echter Service Bus, echte Quell-/Zielsysteme — für Probleme aus einer konkreten Umgebung.

→ Zum Artikel

Gemeinsamkeiten

Beide Varianten teilen sich denselben Code und dieselbe launchSettings.json (Rider/Visual Studio/VS Code starten die DataBridge über dasselbe Projekt src/DataBridge/DataBridge.csproj auf Port 7062). Der Unterschied steckt ausschließlich in src/DataBridge/local.settings.json — welche Connection-Strings dort stehen, entscheidet, wogegen die DataBridge beim Start läuft. Die Datei ist nicht eingecheckt (.gitignore) und wird in beiden Varianten unterschiedlich befüllt:

  • Podman: generiert durch dev/up.sh --host aus der Vorlage dev/local.settings.dev.json.
  • Cloud: von Hand aus src/DataBridge/sample.local.settings.json kopiert und mit echten Werten gefüllt.

Beide Varianten steuern außerdem, ob GetChanges (Timer) und die Process*QueueItems-Funktionen laufen, über dieselben App-Settings (AzureWebJobs.<FunctionName>.Disabled) — nur der Weg dorthin unterscheidet sich (Toggle beim Start vs. Wert von Hand in local.settings.json). Details dazu in den beiden Artikeln.

Gegen Podman debuggen

Die DataBridge lokal mit Breakpoints gegen die Podman-Testumgebung debuggen — konkret in Rider, Visual Studio und VS Code, inklusive Steuerung von GetChanges/Process*QueueItems und Einblick in den Service-Bus-Emulator.

Gegen echtes Azure debuggen

Die DataBridge lokal mit Breakpoints gegen eine echte Azure-Instanz debuggen — konkret in Rider, Visual Studio und VS Code, inklusive Steuerung von GetChanges/Process*QueueItems.