Umgebungsisolation: Wie trennst du Dev, Staging und Prod mit Azure CLI und Subscriptions?

Sechs fast identische .env.example-Dateien wirken gründlich. Sie garantieren Drift. Jemand aktualisiert drei. Prod liest weiter die vierte. Agents und Menschen lösen unterschiedliche Pfade auf. Das Repo sieht konfiguriert aus. Die eigentliche Umgebung ist die Cloud, und niemand ist sich einig, welche Subscription live ist.

Behandle den Kontext in Azure CLI (Subscription, Ressourcengruppe, Identität) als Isolationsgrenze. Halte eine kleine Zahl aktiver Env-Dateien plus Stage-Vorlagen, die Namen dokumentieren, keine Secrets. POC und MVP können sich den Produktcode teilen und trotzdem getrennte Deploy-Stages haben.

Abbildung 1. Dateien beschreiben die Form der Konfiguration. Der Kontext in Azure CLI wählt die echte Umgebung aus. Die richtige Datei plus die falsche Subscription ist trotzdem ein Erfolg in der falschen Welt.

Kontext und Rahmenbedingung

Ein häufiger Fehler: Die Dotenv-Archäologie wächst über die Feature-Arbeit hinaus. Lokale Läufe funktionieren. Slot-Swaps schlagen fehl. Der Bug liegt nicht in Node. Er liegt in vier Vorlagen, die vier leicht unterschiedliche Wahrheiten über denselben Namen in Key Vault erzählen.

Anwendungs-Secrets gehören in Key Vault und App Settings. Vorlagen dokumentieren nur Namen und nicht geheime Standardwerte. Wer redundante Beispiele zusammenlegt, verringert die Stellen, an denen sich Drift verstecken kann. Menschen und Coding Agents sollten Pfade aus einer dokumentierten Quelle der Wahrheit auflösen, nicht aus dem Ordner, den sie zufällig zuerst geöffnet haben.

Abbildung 2 zeigt die Learn-Seite zur Isolation in der Cloud. Subscription, Ressourcengruppe, Identität und Netzwerkgrenzen sind die echten Wände. Env-Dateien benennen nur, was in diesen Wänden stehen soll.

Abbildung 2. Isolation in der Cloud bedeutet Subscription, Ressourcengruppe, Identität und Netzwerk. Env-Dateien beschreiben nur Namen. Quelle: Microsoft Learn: private endpoint overview.

Abbildung 3 zeigt, warum die Isolation von Stages eine Frage des Deployments ist. POC und MVP können sich den Produktcode teilen und trotzdem getrennte Deploy-Stages und Kontexte in Azure CLI haben.

Abbildung 3. POC und MVP können sich den Produktcode teilen und trotzdem getrennte Deploy-Stages und Kontexte in Azure CLI haben. Quelle: Microsoft Learn: App Service deploy best practices.

Design

1. Zwei aktive Dateien und Stage-Vorlagen, nicht sechs Klone

Halte ein minimales Muster für lokale Overrides und explizite Stage-Vorlagen (zum Beispiel POC und MVP oder Test und Prod). Lösche fast identische Beispiele, die sich nur in einem Hostnamen unterscheiden. Wenn ein Wert stage-spezifisch ist, gehört er in eine Stage-Vorlage oder nach Azure, nicht in eine sechste Datei namens "example-final-final". Abbildung 4 zeigt den Wildwuchs, den du löschst, und den Satz, den du behältst.

Abbildung 4. Ein Vorlagensatz, nicht sechs Klone. Wenn jemand ein siebtes Beispiel vorschlägt, frag, welches der sechs schon gelogen hat.

2. Namen in Git, Secrets in Azure

Vorlagen listen die Namen von Einstellungen auf und verweisen auf Referenzen in Key Vault oder App Settings. Sie enthalten keine Connection Strings. Reviewer sollten geheimes Material in Env-Beispielen genauso ablehnen wie committete Zugangsdaten. Für das Onboarding reicht die Dokumentation der Namen.

3. Der Kontext in Azure CLI ist der Umgebungsschalter

Subscription, Ressourcengruppe und die Identität, mit der du deployst, legen fest, wo Änderungen landen. Eine korrekte .env gegen die falsche Subscription ist ein erfolgreiches Deployment in die falsche Welt. Skripte sollten az account show und die Ziel-RG ausgeben und prüfen, bevor sie etwas anwenden. Mach den Kontext in CI-Logs sichtbar. Abbildung 5 zeigt das Gate vor der Änderung.

Abbildung 5. Prüfe Subscription und Ressourcengruppe, bevor du etwas änderst. Sichtbarkeit im Log schlägt Stammeswissen nach einem hektischen Nachmittag.

4. Gemeinsamer Produktcode, getrennte Deploy-Stages

POC und MVP können sich die Anwendung teilen. Sie sollten sich keine Ressourcengruppen teilen, keine App-Registrierungen ohne Absicht und keine "vorübergehenden" Einstellungen, die dauerhaft geworden sind. Die Isolation von Stages ist eine Frage des Deployments. Code-Forks zur Umgebungsisolation sind meist ein Fehler.

5. Eine einzige Art der Pfadauflösung für Menschen und Agents

Dokumentiere die kanonischen Pfade für Vorlagen, lokale Overrides und Deploy-Parameterdateien. Coding Agents, die einen dritten Ort für Env-Dateien erfinden, erzeugen Drift in Maschinengeschwindigkeit neu. Leg die Übersicht in die README oder in ein kurzes Ops-Dokument neben die Vorlagen.

6. Schlag im Zweifel fehl, wenn Pflichtnamen fehlen

Start- oder Deploy-Prüfungen sollten fehlschlagen, wenn erforderliche App Settings fehlen, statt still auf die Werte einer benachbarten Stage zurückzufallen. Freundliche Standardwerte, die den falschen Speicher erreichen, sind in Produktion feindselig.

Agents machen Drift lauter

Coding Agents legen bereitwillig .env.local2 an und codieren eine Ressourcengruppe fest, die sie in einem alten Transkript gesehen haben. Begrenze sie mit derselben Pfadübersicht, die auch Menschen nutzen. Bevorzuge Skripte, die --stage annehmen und alles andere aus dokumentierten Vorlagen plus dem Kontext in Azure CLI auflösen. Wenn ein Agent in einer Session einen neuen Env-Dialekt erfinden kann, war dein Isolationsmodell schon für Menschen zu unscharf.

Ein minimales Vorlagenlayout, das den Praxistest übersteht

Ein Abschnitt in der README benennt die aktive Override-Datei, die Stage-Vorlagen und die Azure-Ziele, die diese Vorlagen beschreiben. Deploy-Skripte lesen die Stage als Argument, setzen Subscription und Ressourcengruppe explizit und wenden dann an. Lokale Entwickler kopieren einmal eine Vorlage und halten Secrets aus Git heraus. Wenn jemand eine siebte Beispieldatei vorschlägt, frag, welche der sechs schon gelogen hat. Meist lautet die Antwort "mehr als eine".

Gib die aufgelöste Subscription-ID und Ressourcengruppe am Anfang jeder Deploy-Logzeile aus, die Menschen lesen. Sichtbarkeit schlägt Stammeswissen, wenn nach einem hektischen Nachmittag jemand fragt: "Welche Umgebung haben wir gerade angefasst?"

Stage-Namen in Skripten sollten den Stage-Namen der Azure-Ressourcengruppen so nahe kommen, dass eine fremde Person sie ohne Dechiffrierscheibe zuordnen kann.

Häufige Fehler

Wildwuchs bei Vorlagen. Sechs Beispiele, vier veraltet, zwei falsch.

Secrets in Git, "nur für lokal". Sie leaken. Rotieren für immer.

Richtige Datei, falsche Subscription. Grünes Deployment, falscher Blast Radius.

POC-Einstellungen aus Gewohnheit ins MVP kopiert. Annahmen zu Netzwerk und Identität reisen unbezahlt mit.

Von Agents erfundene Env-Pfade. Automatisierung verstärkt Folklore.

Stille Fallbacks zwischen Stages. Falscher Key Vault, korrektes HTTP 200.

So übernehmen oder anpassen

So übernehmen

• Ein kanonischer Satz Env-Vorlagen (Anzahl und Namen), in Git eingecheckt.
• Secrets nur in Key Vault / App Settings; Vorlagen dokumentieren Namen.
• Deploy-Skripte prüfen Subscription und RG in Azure CLI, bevor sie etwas ändern.
• POC und MVP (oder Test/Prod) nutzen getrennte Ressourcengruppen und Stage-Einstellungen.
• Eine einzige dokumentierte Pfadübersicht für Menschen und Agents.
• Start/Deployment schlägt fehl, wenn Pflichteinstellungen fehlen.

Vor dem Einsatz anpassen

Weniger Vorlagen bedeuten weniger Copy-paste-Onboarding und mehr Abhängigkeit davon, dass Leute sich im Azure-Portal oder in der CLI auskennen. Das ist die richtige Fähigkeit für Cloud-Apps. Strenge Kontextprüfungen kosten Skripte ein paar Sekunden und verhindern wochenlange Geschichten über Fehl-Deployments. Gemeinsamer Code über Stages hinweg verlangt Disziplin bei Feature Flags und Namen von Einstellungen; die Alternative sind auseinanderlaufende Forks, die nie zusammengeführt werden. Referenzen auf Key Vault fügen bewegliche Teile hinzu. Sie schlagen Env-Dateien im Klartext im Repo.

Wichtigste Quellen: Microsoft Learn zu Azure CLI configuration, App Service app settings und Key Vault references.

Isoliere mit Disziplin in Azure CLI, verkleinere den Vorlagensatz, halte Secrets in Azure und mach den Kontext unübersehbar. Drift schrumpft, wenn die Grenze in der Cloud die Grenze ist, die du tatsächlich nutzt.

Verwandte Notizen

• CI-Gates: Was sicherst du in Azure DevSecOps Pipelines wirklich ab? (was eine CI-Pipeline vor dem Release blockieren sollte)