Releases, die deine Daten schützen, bevor sie starten
· 3 Min. Lesezeit

Während du einen Film machst, veröffentlichen wir vielleicht gerade eine neue Version von PageToVid unter dir. Deine Projekte, Storyboards und Filme liegen in einer Datenbank, und ein Release, das ihre Form ändert, berührt alle auf einmal. Eines sollte unmöglich sein: dass ein Release still und leise etwas verschwinden lässt, das dir gehört.
Eine neue Version, derselbe sichere Boden
Wir veröffentlichen oft, manchmal mehrmals am Tag. Die meisten Releases ändern nur Code, manche aber auch die Datenbank: eine neue Tabelle für eine neue Funktion, ein neues Feld an einem Film.
Das Versprechen dahinter passt in einen Satz. Nichts, was du gemacht hast, darf davon abhängen, dass ein Release gut geht. Stimmt mit einer neuen Version etwas nicht, soll die alte dich weiter bedienen, und deine Daten bleiben genau so, wie sie waren.
Die Prüfung, die jede Version an der Tür besteht
Wenn eine neue Version von PageToVid startet, bringt sie die Datenbank auf den neuesten Stand, bevor sie auch nur eine Seite ausliefert, und zwar mit Prisma, dem Werkzeug, das unsere Tabellen beschreibt. Diesen Schritt führen wir bewusst ohne die Option aus, die Datenverlust akzeptiert.
Würde eine Änderung eine Spalte löschen, ein Feld so umwandeln, dass Werte verloren gehen können, oder bestehende Zeilen sonst gefährden, verweigert der Schritt. Die neue Version hält an, bevor sie irgendeinen Verkehr annimmt, und Cloud Run, das unsere Server betreibt, lässt die vorherige Version weiterlaufen, als wäre nichts gewesen.
Damit folgt jede Datenbankänderung einer Regel, nur Neues hinzufügen:
- neue Tabellen
- neue optionale Felder
- neue Felder mit Standardwert
Alles andere wartet an der Tür, bis es eine andere Form bekommt.
Eine Regel, die leer aussieht, es aber nicht ist
Dieses Release brachte kurze, lesbare Links, die sich jede Person selbst aussuchen kann, und zwei Personen dürfen nie denselben haben. Die naheliegende Schreibweise: ein neues Feld an der bestehenden Kontotabelle, als eindeutig markiert.
Das Feld war ganz neu und leer. Es wirkte harmlos. Aber eine neue Eindeutigkeitsregel auf einer Tabelle, die schon Zeilen enthält, gilt als möglicher Verlust, denn die Datenbank kann nicht im Voraus garantieren, dass keine zwei Zeilen kollidieren. Die Prüfung an der Tür tat also genau ihre Arbeit: Die Version mit dieser Regel wartete, die vorherige lief weiter, und niemand, der gerade einen Film machte, merkte etwas.
Unsere Tests konnten das nicht sehen. Sie bauen jedes Mal eine frische, leere Datenbank, und auf einer leeren Tabelle sieht ein eindeutiges Feld an einer neuen Tabelle genauso aus wie an einer bestehenden. Den Unterschied gibt es nur dort, wo echte Daten liegen, genau dort, wo die Wache steht.
Die Daten umformen, die Wache behalten
Die schnelle Antwort wäre gewesen, die Option für Datenverlust einzuschalten und zu veröffentlichen. Wir haben das Gegenteil getan. Wir haben die Form der Daten geändert, damit sie die Prüfung ehrlich bestehen.
Eine Regel, die zusammen mit einer neuen Tabelle entsteht, ist sicher, denn eine neue Tabelle hat keine Zeilen, die kollidieren könnten. Also zog die Eindeutigkeit dieser Links in eine kleine eigene Tabelle, mit dem Link selbst als Schlüssel und einer Zeile pro Person. Das Konto behält eine einfache Kopie für die Anzeige, ohne Regel.
Die Änderung wurde rein additiv. Das haben wir vor dem Release gegen die laufende Datenbank geprüft, und die Funktion ging noch am selben Tag live.
Ein Schritt mehr vor jeder Datenbankänderung
Die Lehre ist jetzt Teil unserer Releases. Bevor eine Datenbankänderung rausgeht, vergleichen wir sie mit dem Schema, das tatsächlich läuft, nicht mit der Kopie eines Entwicklers:
- das Schema der aktuell laufenden Version nehmen, und das neue
- Prisma nach den genauen Anweisungen fragen, die es zwischen beiden ausführen würde
- sie lesen: nur neue Tabellen, optionale Felder oder Felder mit Standardwert, und Eindeutigkeitsregeln auf neuen Tabellen
- vor dem Release ein frisches Backup ziehen
Was auf einer bestehenden Tabelle nie auftauchen darf: eine neue Eindeutigkeitsregel, ein Pflichtfeld ohne Standardwert, eine Umbenennung oder eine Löschung. Für jedes davon gibt es eine bekannte sichere Form, meist eine neue Tabelle.
Was das für deine Filme bedeutet
Du siehst davon nichts, und genau darum geht es. Eine Version, die nicht bereit ist, startet einfach nicht, die, die du nutzt, läuft weiter, und deine Projekte und Filme bleiben genau so, wie du sie verlassen hast.
Ein Release, das an der Tür wartet, ist für uns eine kleine Verzögerung. Ein verschwundenes Feld wäre für dich ein Verlust. Wir haben uns für den Tausch entschieden, der deine Arbeit schützt. Mehr Geschichten darüber, wie PageToVid entsteht, findest du im Blog.
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.
Weiterlesen


