# Debuggen

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

---

Site [llms.txt](/llms.txt)

---

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:

<div class="td-card-group card-group p-0 mb-4">
<div class="td-card card border me-4">
<div class="card-header">
      <strong>Gegen Podman debuggen</strong>
    </div>
<div class="card-body">
    <p class="card-text">
        <p>Azurite, Podman-Datenbanken, Service-Bus-Emulator, WireMock — alles lokal, keine Azure-Kosten,
jederzeit zurücksetzbar.</p>
<p><a href="/entwicklung/debuggen/podman/">→ Zum Artikel</a></p>
</p>
      </div>
  </div>

<div class="td-card card border me-4">
<div class="card-header">
      <strong>Gegen echtes Azure debuggen</strong>
    </div>
<div class="card-body">
    <p class="card-text">
        <p>Echter Storage Account, echter Service Bus, echte Quell-/Zielsysteme — für Probleme aus einer
konkreten Umgebung.</p>
<p><a href="/entwicklung/debuggen/cloud/">→ Zum Artikel</a></p>
</p>
      </div>
  </div>

</div>


## 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.

---

Section pages:

- [Gegen Podman debuggen](/entwicklung/debuggen/podman/): 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](/entwicklung/debuggen/cloud/): 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.