Was Preview-Umgebungen tatsächlich kosten
Die Kosten von Preview-Umgebungen steigen mit der Zahl offener Pull Requests, nicht mit der Teamgröße. Erfahren Sie, wo sich die Ausgaben verstecken, welche Komponenten gemeinsam genutzt werden können und wie Sie Previews automatisch ablaufen lassen, damit fünf offene PRs nicht zu fünf Stacks werden.
Preview-Umgebungen gehören zu den Maßnahmen mit dem größten Hebel, die ein Team aktivieren kann. Ein Reviewer klickt auf einen Link und nutzt die Änderung, statt einen Diff zu lesen und sich das Ergebnis vorzustellen. Designfehler werden vor dem Merge erkannt. QA ist keine eigene Phase mehr.
Gleichzeitig sind sie der Kostenposten, der Ihre Rechnung am ehesten unbemerkt verdreifacht – und der Grund dafür ist eine einfache Rechnung, die niemand in dem Moment anstellt, in dem die Funktion aktiviert wird.
Die Rechnung
Die Kosten einer Preview-Umgebung steigen mit der Zahl der offenen Pull Requests, nicht mit der Zahl der Teammitglieder oder der Merges.
Ein vierköpfiges Team mit einer gesunden Review-Kultur hat zu jedem Zeitpunkt vielleicht fünf bis acht offene PRs. Wenn für jeden davon eine vollständige Kopie Ihres Stacks bereitgestellt wird, betreiben Sie zusätzlich zur Produktion fünf bis acht weitere Kopien. Ein Stack, dessen Betrieb 30 $ pro Monat kostet, schlägt nun mit 180–270 $ zu Buche. In keiner Schätzung tauchte dieser Betrag auf, weil sich die Schätzung auf eine Umgebung bezog.
Noch problematischer: Offene PRs häufen sich gerade in Phasen, in denen Sie Überraschungen am wenigsten gebrauchen können – vor einem Release, während eines Refactorings oder wenn jemand im Urlaub ist und der eigene Branch drei Wochen offen bleibt.
Wohin das Geld tatsächlich fließt
Nicht jeder Bestandteil einer Preview verursacht dieselben Kosten. Zu wissen, welcher Teil wie viel kostet, macht die Ausgaben kontrollierbar.
Application-Container – moderat und ihr Geld wert. Das ist der Teil, den Sie tatsächlich benötigen. Außerdem lässt er sich gut herunterdimensionieren, weil eine Preview nicht den Arbeitsspeicher der Produktion braucht.
Datenbanken – der teure Teil. Eine dedizierte Datenbank pro Preview ist der größte einzelne Kostenfaktor und meistens am wenigsten notwendig. Die meisten Reviews benötigen keine isolierte Datenbank, sondern eine Datenbank mit plausiblen Daten.
Build-Minuten – unsichtbar und kumulativ. Jeder Push auf einen offenen PR löst einen neuen Build aus. Ein Branch mit vierzig Commits über zwei Wochen wird vierzigmal gebaut. Das sind reale Kosten, die nie als laufende Ressource angezeigt werden und deshalb bei der gedanklichen Prüfung vollständig untergehen.
Egress – pro Preview gering, insgesamt erheblich. Preview-URLs werden entdeckt und gecrawlt. Ein Crawler, der Ihre Assets aus acht Preview-Umgebungen abruft, verursacht achtmal so viel Arbeit wie beim Abruf aus der Produktion – und Sie bezahlen für alles.
Vier Maßnahmen, die Kosten senken, ohne den Nutzen zu verlieren
Datenbank gemeinsam nutzen
Für die meisten Änderungen können Previews eine gemeinsame Datenbank mit repräsentativen Testdaten verwenden. Reservieren Sie isolierte Datenbanken für PRs, die sie tatsächlich benötigen – Migrationen, Schemaänderungen und alles, was destruktiv ist.
Die Regel, die sich in der Praxis bewährt: isolierte Datenbank nur, wenn der PR das Schema verändert. Alles andere wird gemeinsam genutzt.
Preview herunterdimensionieren
Eine Preview, die von einem Reviewer genutzt wird, benötigt nicht die Ressourcen der Produktion. Die Hälfte des Arbeitsspeichers und ein Bruchteil der CPU-Leistung sind für die reviewende Person normalerweise nicht bemerkbar, aber deutlich günstiger.
dockup resources my-project/my-api --memory 512 --cpu 0.5
Previews ablaufen lassen
Die Maßnahme mit der größten Wirkung. Eine Preview sollte ihren Pull Request nicht überleben.
Automatisches Entfernen beim Mergen oder Schließen gehört zur Grundausstattung. Was Teams häufig übersehen, ist der aufgegebene PR – der Branch, den jemand geöffnet hat, danach aber nicht weiterverfolgt und nie geschlossen wurde. Solche Umgebungen laufen monatelang weiter.
Ein maximales Alter ist daher eine sinnvolle Absicherung: Jede Preview, die beispielsweise älter als vierzehn Tage ist, wird unabhängig vom Status des PRs entfernt. Falls sie wieder benötigt wird, lässt sie sich mit einem einzigen Befehl erneut erstellen.
Previews aus der Suche heraushalten
Preview-URLs werden indexiert. Das ist aus zwei Gründen problematisch: Duplicate Content konkurriert mit Ihrer Produktionswebsite, und für Umgebungen, die niemand nutzt, fällt Crawler-Traffic an, den Sie trotzdem bezahlen.
dockup noindex my-project/my-api --on
In Dockup gelten PR-Previews pro Service und können explizit aktiviert oder deaktiviert werden, statt eine globale Einstellung zu sein, die automatisch übernommen wird:
dockup pr-preview my-project/my-api --on
dockup preview list my-project/my-api --json
dockup preview delete 128 my-project/my-api
Das Auflisten ist der Schritt, den Teams überspringen und später bereuen. Umgebungen, die Sie nicht vollständig erfassen können, sind Umgebungen, für die Sie bezahlen, ohne es zu wissen.
Das monatliche Audit, das sich lohnt
Drei Fragen, fünf Minuten:
- Wie viele Previews laufen? Vergleichen Sie diese Zahl damit, wie viele PRs tatsächlich offen sind.
- Wie alt ist die älteste? Alles, was älter als zwei Wochen ist, wurde mit hoher Wahrscheinlichkeit aufgegeben.
- Welche Previews haben eine eigene Datenbank? Was keine Schemaänderung ist, benötigt wahrscheinlich keine eigene Datenbank.
Die meisten Teams finden mindestens eine Umgebung aus einem PR, der vor Monaten gemergt wurde, aber immer noch läuft und weiterhin Kosten verursacht.
Den Nutzen ohne Überraschungen erhalten
Nichts davon spricht gegen Preview-Umgebungen. Es spricht dafür, sie als Infrastruktur mit einem Lebenszyklus zu behandeln und nicht als Checkbox.
Teams, die das richtig machen, tun drei Dinge: Sie dimensionieren Previews herunter, lassen sie ablaufen und teilen sicher gemeinsam nutzbare Ressourcen. So bleibt der gesamte Footprint der Previews normalerweise unter den Kosten eines einzelnen Produktionsservices – ein Preis, bei dem sich ihr Einsatz offensichtlich lohnt.
Teams, die überrascht werden, sind diejenigen, die Previews einmal korrekt aktiviert und danach nie wieder in die Liste geschaut haben.
Häufig gestellte Fragen
Kosten Preview-Umgebungen genauso viel wie die Produktion? Pro Umgebung können sie genauso viel kosten, wenn sie identisch bereitgestellt werden. Eine herunterdimensionierte Preview mit gemeinsamer Datenbank kostet typischerweise nur einen Bruchteil der Produktionsumgebung.
Sollte jede Preview eine eigene Datenbank haben? Nur wenn die Änderung das Schema betrifft. Eine gemeinsame, mit Testdaten befüllte Datenbank reicht für die meisten Reviews aus und beseitigt den größten Kostenfaktor.
Was passiert mit einer Preview, wenn der PR geschlossen wird? Sie sollte automatisch entfernt werden. Andernfalls sammeln sich Umgebungen von PRs an, an die sich niemand mehr erinnert.
Beeinträchtigen Preview-Umgebungen die SEO?
Das können sie, wenn sie indexiert werden – Duplicate Content konkurriert dann mit Ihren Produktionsseiten. Markieren Sie sie mit noindex; dadurch verhindern Sie außerdem, dass Crawler Traffic erzeugen, für den Sie bezahlen.