Pipeline

Kontrollierte Datenauffrischung

Ein Register aller Datenquellen und ein einheitlicher Ablauf, der jede Quelle neu abruft, den Unterschied berichtet statt still zu überschreiben und erst mit der veröffentlichten Seite endet.

Status Produktiv im Kanu-Projekt – 5 Quellen im Register, Historie je Lauf
Ort update.py als Dirigent, _update/quellen.yaml als Register
Prinzip Der Diff ist der Bericht – Änderungen werden vorgelegt, nicht angenommen

Worum es geht

Ein Datensatz aus Webquellen ist beim ersten Lauf richtig und ab dem zweiten Tag veraltet. Die eigentliche Schwierigkeit liegt deshalb nicht im ersten Abruf, sondern im zweiten: Er muss erkennen, was sich geändert hat, darf Handarbeit nicht zerstören und soll nicht ungefragt Geld kosten.

Ohne feste Strecke wird stattdessen jede Quelle einzeln von Hand nachgezogen – unterschiedlich gründlich, zu unterschiedlichen Zeitpunkten, und niemand weiß hinterher, welcher Stand woher stammt. Der Baustein macht daraus einen einzigen, quellen-unabhängigen Ablauf: Abruf → Unterschied → Historie → Veröffentlichung.

Das Register als einzige Stellschraube

Jede Datenquelle ist ein Eintrag in einer Registerdatei: Anzeigename, Abruf-Skript, erzeugte Rohdaten-Datei, das Feld das einen Datensatz eindeutig macht, die für einen echten Frischabruf zu leerenden Zwischenspeicher – und ob die Quelle kostenpflichtig ist.

Eine neue Quelle aufzunehmen heißt: einen Eintrag ergänzen. Die bestehenden Abrufe bleiben unangetastet, und der Ablauf selbst muss nicht angefasst werden.

Sechs Regeln, die den Unterschied machen

  • Der Diff ist der Bericht. Je Quelle wird ausgewiesen, wie viele Datensätze vorher da waren, wie viele jetzt, und wie viele neu, geändert oder entfallen sind. Ein Lauf, der nichts meldet, hat nichts verändert – das ist eine Aussage, kein Schweigen.
  • Kostenpflichtige Quellen laufen nicht mit. Sie sind im Register markiert und standardmäßig aus; sie starten nur nach ausdrücklicher Bestätigung. Kosten entstehen nie als Nebenwirkung einer Routine.
  • Handkorrekturen überleben jeden Lauf. Die Korrekturdatei ist bewusst keine Quellen-Ausgabe und wird vom Auffrischungslauf nie geschrieben – sie wird stromabwärts erneut angewendet. Sonst löscht der nächste Abruf die Nacharbeit von Wochen.
  • Widersprüche zwischen Quellen werden zur Arbeitsliste, nicht zur stillen Entscheidung. Sagt Quelle A etwas anderes als Quelle B, steht der Fall auf einer Prüfliste, bis jemand entscheidet.
  • Ein Frischabruf muss frisch sein. Alle Quellen halten einen lokalen Zwischenspeicher, damit Neuläufe schnell und schonend sind. Genau deshalb braucht es einen ausdrücklichen Befehl, der ihn leert – sonst prüft man den alten Stand gegen sich selbst und hält ihn für bestätigt.
  • Ein Update endet erst veröffentlicht. Zum Lauf gehören Arbeitsmappe, Karte, Webseite und Deployment. Lokal aktuelle Daten hinter einer veralteten Seite sind für jeden Betrachter schlicht nicht aktualisiert.

Historie: was lief wann, mit welchem Ergebnis

Jeder Lauf hinterlässt je Quelle einen Eintrag mit Zeitpunkt, Ergebnis und dem vollständigen Unterschied. Damit lässt sich später beantworten, wann ein Wert zuletzt bestätigt wurde und ob eine Auffälligkeit im Datensatz aus der Quelle stammt oder aus einer Änderung an der eigenen Verarbeitung.

Die Historie wird zusätzlich in die Wissensbasis gespiegelt, damit sie auch dort auffindbar ist, wo über die Daten gesprochen wird – nicht nur dort, wo sie erzeugt werden.

Für Teilausfall gebaut

Nicht jeder Schritt ist überall verfügbar. Der Kalender-Abgleich etwa braucht ein installiertes Outlook und läuft deshalb als letzter Schritt: Fehlt es, überspringt sich der Schritt mit sichtbarer Meldung, statt den Lauf abzubrechen. Ein echter Schreibfehler wird dagegen gemeldet und macht den Lauf rot.

Die Reihenfolge ist damit kein Zufall, sondern eine Entscheidung darüber, welcher Ausfall welchen Rest noch kosten darf.

Eingesetzt in

← zurück zur Baustein-Übersicht