Serie
Eine Serie über die Systeme, die bei Squibble tatsächlich im Einsatz sind – was sie lösen, wie sie aufgebaut sind und was wir beim Bauen gelernt haben.
Workbench darf seine Datenbank wegwerfen und neu aufbauen. Diese Anwendung pollt Graylog und legt GitLab-Issues an, und ein Seiteneffekt hat kein Upstream. Warum Dry-Run zur Datenbankspalte wurde, warum das Dashboard keinen Löschen-Knopf hat, und warum die Schutzschranke an der HTTP-Grenze sitzt statt in der Konfiguration.
Ein Security-Review hat darauf hingewiesen, dass unser Secrets-Manager seinen eigenen Administratoren vertraut. Die Antwort war Zero-Knowledge-Ende-zu-Ende-Verschlüsselung, und der ehrliche Teil des Entwurfs ist die Liste der drei Stellen, an denen der Server trotzdem Klartext sieht, und warum wir jede davon akzeptiert haben.
Wir haben eine mandantenfähige Sicht über mehrere GitLab-Instanzen gebaut, ohne zur zweiten Wahrheit zu werden. Die Regel, die das trägt: die lokale Datenbank ist wegwerfbar, und korrekt macht sie die Reconciliation, nicht die Webhooks.
Jedes Board scheitert irgendwann daran, dass es zur zweiten Wahrheit wird: es merkt sich, in welcher Spalte eine Karte liegt, und ab da muss dieses Wissen gepflegt werden. Workbench merkt es sich gar nicht: Spalten sind Regeln, die beim Lesen ausgewertet werden.
16’300 CI-Minuten in einer Woche, 18.9 % kompletter Ausschuss und 22 Release-Versuche für eine einzige Anwendung: Warum Releases als Testumgebung missbraucht wurden, wieso Agenten ohne Governance lautlos Standards ignorieren, und wie ein dreistufiger Filter das Problem löst.
Eine rote oder langsame Pipeline ist nur ein Symptom. Workbench verbindet verlorene Runner-Zeit, Job-Trends und Pipeline-Wasserfälle zu einer Untersuchung, die bis zum konkreten Merge-Request-Versuch führt.
Workbench bringt Änderungen aus GitLab in weniger als fünf Sekunden in einen offenen Browser. Der Webhook beschleunigt den Weg, doch die Wahrheit bleibt bei GitLab und die lokale Projektion bleibt wegwerfbar.
