Zum Hauptinhalt springen
Engineering

Releases, die sich selbst prüfen, bevor du sie siehst

· 3 Min. Lesezeit

Anfang Juli haben wir Verbesserungen an PageToVid mehrmals am Tag veröffentlicht, manchmal direkt hintereinander. Jede sollte schnell bei dir ankommen, und keine sollte dich je auf einer Seite zurücklassen, die nicht funktioniert. Am 4. Juli hat unsere Release-Pipeline gelernt, ihre eigene Arbeit von außen zu prüfen und sie selbstständig rückgängig zu machen.

Mehrmals am Tag veröffentlichen

Schon seit dem allerersten Commit hatte PageToVid eine Pipeline, die die Typen im Code prüft, einen Container mit allem baut, was ein Film braucht, vom Browser bis zur Video-Engine, und ihn auf Google Cloud Run ausrollt. Dieses Tempo sorgt dafür, dass eine Korrektur, die wir am Montagmorgen finden, schon am Nachmittag in deinem nächsten Film steckt.

Anfang Juli konnte die Pipeline mehr. Jedes Release startet sauber und löst alles, was die vorige Version angebunden hatte, damit nichts Altes in der neuen weiterlebt. Und der Job, der Filme rendert, wird aus genau demselben Image ausgerollt, aus dem die Website gebaut wurde, also laufen Website und Renderer immer mit demselben Code.

Fertig heißt noch nicht live

Wenn der letzte Schritt eines Releases gelang, wurde der Job grün. Aber Grün hieß nur, dass die Plattform die neue Version angenommen hatte. Über drei Dinge, die uns wirklich wichtig waren, sagte es nichts:

  • ob Besucher wirklich den neuen Code erreichen und nicht eine Kopie aus einem Cache vor der Website
  • ob die neue Version mit ihrer Datenbank sprechen kann
  • welcher Commit in diesem Moment genau antwortet

Ein Release, das sich selbst nicht sehen kann, ist eine Vermutung. Wir wollten, dass jedes Release von außen beweist, dass es wirklich ausliefert und wirklich gesund ist.

Jeder Build trägt seinen Namen

Der erste Schritt war Nachvollziehbarkeit. Jedes Release schreibt jetzt seinen Commit, seinen Branch, seinen Pipeline-Lauf und seine Build-Zeit in den laufenden Dienst. Sie tauchen an zwei Stellen auf:

  • ein Health-Endpunkt, der Status, Commit, eine Live-Prüfung der Datenbank und die Laufzeit meldet und nie gecacht wird
  • ein Versions-Header auf jeder Antwort der Website

Jede laufende Version trägt außerdem den Namen ihres Pipeline-Laufs und ein Etikett mit ihrem Commit, also gehört jede Version zu genau einem Commit. Wirkt ein Film oder eine Seite seltsam, hat die erste Frage, welcher Code ist das, jetzt eine Antwort in einer Sekunde.

Eine Prüfung mit dem Blick von außen

Nach dem Ausrollen fragt die Pipeline diesen Health-Endpunkt jetzt über den öffentlichen Netzwerkrand ab, also genau auf dem Weg, den auch Besucher nehmen, am Cache vorbei. Sie fragt so lange, bis die Antwort genau den gerade ausgerollten Commit und eine funktionierende Datenbank nennt. Passiert das nicht rechtzeitig, schlägt das Release fehl.

Dass die Prüfung über den Netzwerkrand läuft und nicht über die eigene Adresse des Dienstes, ist entscheidend. So wird getestet, was du tatsächlich erreichst, einschließlich allem, was vor der App sitzt. Ein Release ist erst fertig, wenn die Außenwelt es sieht.

Die Datenbankprüfung ist aus demselben Grund wichtig. Eine Version, die startet, ihre Daten aber nicht erreicht, würde einen einfachen Ping beantworten und trotzdem bei jeder echten Anfrage scheitern. Der Health-Endpunkt spricht selbst mit der Datenbank und meldet das Ergebnis, also bemerkt die Prüfung es lange vor dir.

Von selbst einen Schritt zurück

Schlägt die Prüfung fehl, leitet die Pipeline den Verkehr sofort auf die Version zurück, die vorher lief. Niemand muss es bemerken, aufwachen oder einen Befehl tippen: Ein Release, das sich nicht beweisen kann, bleibt einfach nicht. Jeder Lauf endet mit einer kurzen Übersicht, was ausgerollt wurde, was die Prüfung gesehen hat und was danach geschah.

Außerdem behalten wir den Build-Cache zwischen den Läufen, was jeden neuen Build deutlich schneller macht. Das zählt mehr, als es klingt. Je schneller eine Korrektur gebaut ist, desto weniger kostet ein Schritt zurück und ein neuer Versuch, und desto früher erreicht die Verbesserung deine Filme.

Was das für deinen Film bedeutet

Von alldem siehst du nichts, und genau darum geht es. Du fügst einen Link ein, und die Seite, die antwortet, ist die Version, die gerade ihre Prüfung bestanden hat, mit ihren Daten verbunden und mit demselben Code wie der Renderer, der deine Website filmen wird. Ist etwas Neues noch nicht bereit, bedient dich die vorige Version weiter, ohne Unterbrechung.

So können wir PageToVid mehrmals am Tag verbessern, ohne dich auf ein Wartungsfenster warten zu lassen. Wenn du auf PageToVid aufbaust, erklärt die Entwicklerseite die API, die auf dieser Pipeline läuft, oder du erstellst einfach einen Film.

Sieh es auf deiner eigenen Website

Füge eine Seite ein und bekomme das vertonte Video, um das es in diesem Blog geht. Das erste ist kostenlos.

Erstes Video gratis · keine Kreditkarte · in Minuten fertig

← Alle Artikel