Vorschauumgebungen pro Branch: eine deployte Kopie pro Pull Request, abgebaut beim Merge

Ziel

Jeder Pull Request erhält eine laufende, erreichbare Kopie der Anwendung unter einer eigenen URL, erstellt von der Pipeline und entfernt, sobald der Branch gemerged oder geschlossen wird, damit Reviewende, Testende und Agenten die Änderung ausprobieren können, statt sie sich anhand des Diffs vorzustellen.

Voraussetzungen

Ein deploybares Artefakt pro Commit (Container-Image oder statisches Bundle), eine Infrastruktur, die viele kleine Kopien günstig hosten kann, sowie ein Benennungsschema von der Pull-Request-Nummer zum Hostnamen. Gehostete Plattformen bieten dies für statische und serverlose Sites: Netlify beschreibt Deploy-Previews als das Deployen von Pull- oder Merge-Requests auf eine eindeutige URL mit dem Präfix deploy-preview-<number>. Für Dienste auf einem Cluster bieten Kubernetes-Namespaces einen Mechanismus, um Gruppen von Ressourcen innerhalb eines einzelnen Clusters zu isolieren, was einen Namespace pro Pull Request zur natürlichen Einheit macht.

Schritte

1. Einmal pro Commit bauen und das Artefakt mit dem Commit-SHA taggen; die Vorschau deployt dieses Artefakt, niemals einen Neubau.
2. Den Umgebungsnamen von der Pull-Request-Nummer ableiten (pr-1234), nicht vom Branch-Namen, der Zeichen enthalten kann, die für Hostnamen ungeeignet sind, und umbenannt werden kann.
3. Die Kopie bereitstellen: einen Namespace oder Stack, eine Datenbank, die aus dem lokalen Seed befüllt wird (siehe den verwandten Artikel), eine Konfiguration, die auf Mock- oder Sandbox-Versionen von Drittanbietern zeigt, sowie einen Wildcard-DNS-Eintrag mit passendem Zertifikat, sodass keine DNS-Änderung pro Vorschau nötig ist.
4. Die URL im Pull Request veröffentlichen und als Deployment registrieren. GitHub-Umgebungen tragen Deployment-Schutzregeln und umgebungsgebundene Secrets, sodass Vorschauen eigene, schwächere Zugangsdaten erhalten können.
5. Beim Merge, Schliessen oder nach einem Inaktivitäts-Timeout abbauen und dabei Artefakte und Daten mitlöschen; nächtlich einen Durchlauf gegen verwaiste Umgebungen ausführen.
6. Gleichzeitige Vorschauen und Ressourcen pro Vorschau begrenzen; eine Warteschlange ist besser als ein Cluster, der zusammenbricht.
7. Den End-to-End-Smoke-Test auf die Vorschau-URL richten, damit die Pipeline prüft, dass die Kopie tatsächlich startet.

Erwartetes Ergebnis

Eine reviewende Person öffnet den Link aus dem Pull Request, probiert die Änderung an den Seed-Daten aus, und die Umgebung verschwindet nach dem Merge, ohne dass sich jemand ans Löschen erinnern muss.

Grenzen und Prüfbasis

Vorschauen, die sich ein zustandsbehaftetes Backend teilen (eine Datenbank oder Warteschlange für alle), lassen Änderungen zwischen Branches durchsickern; zustandsbehaftete Dienste brauchen eine Kopie oder ein Schema pro Vorschau. Migrationen, die sich schwer zurückrollen lassen, vertragen sich schlecht mit Abbau und Neuaufbau. Die Kosten wachsen mit der Anzahl offener Pull Requests. Das Vorgehen ist eine Zusammenfassung der zitierten Plattformdokumentation; es werden keine Durchsatz- oder Kostenzahlen behauptet.