Wie wir bauen
Tempo ist hier eine Folge der Kontrollpunkte, kein Weg an ihnen vorbei.
Der berechtigte Einwand gegen ein kleines Team mit vier ausgelieferten Produkten lautet, dass etwas übersprungen worden sein muss. Diese Seite ist die Antwort: was die Maschine tut, was sie nicht darf, und was eine Änderung überstehen muss, bevor sie in die Produktion geht.
Alles Folgende läuft auf unserer eigenen Arbeit. Es ist kein Produkt, das wir verkaufen, und keine Demo.
Die Plattform
Ein privater Marktplatz aus Orchestratoren, Subagenten, Skills und Hooks.
Die Baumaschine ist ein versionierter interner Plugin-Marktplatz, installiert in jedem Repository, in dem wir arbeiten. Sechs Plugins decken Entwicklung, Betrieb, Dokumentation, Vertrieb und die Werkzeuge ab, die weitere Werkzeuge bauen. Allein das Entwicklungs-Plugin trägt 24 Subagenten und 52 Skills.
Die Zahlen entsprechen dem installierten Marktplatz und ändern sich, während die Plattform wächst.
Drei Schichten, mit Absicht
Aufgaben-Orchestratoren
Ein Einstiegspunkt je Art von Arbeit: eine Änderung umsetzen, einen Fehler diagnostizieren, ein Review fahren, Abhängigkeiten aktualisieren. Der Orchestrator bemisst die Aufgabe zuerst und startet nur, was ihr Umfang rechtfertigt.
Skills
Mittlere Routinen, die die Orchestratoren wiederverwenden: entscheiden, welche Verifier eine Änderung braucht, die Teststufe wählen, eine Übersetzung über alle Sprachen verteilen. Einmal geschrieben, überall aufgerufen.
Leaf-Agenten
Schmale Arbeiter mit schmalem Werkzeug. Ein Ingenieur, der eine Schicht schreibt. Ein Verifier, der nur bestanden oder nicht bestanden meldet. Ein Auditor, der liest und nie schreibt. Ein Leaf, der nur lesen kann, kann nichts kaputt machen.
Automatisiert und menschlich freigegeben
Die Linie zwischen dem, was unbeaufsichtigt läuft, und dem, was auf einen Menschen wartet.
Diese Aufteilung ist keine Geschmacksfrage. Was sich wiederholen und maschinell prüfen lässt, ist automatisiert. Was im Fehlerfall teuer, unumkehrbar oder eine Ermessensfrage ist, hält an und wartet.
Wie eine Änderung durch die Plattform läuft
Recherche
- codebase-researcherkartiert die Schichten vor dem Schreibenfertig
Schreiben, parallel und in einer Sandbox
- backend-engineerService und Endpunktfertig
- frontend-engineerSeite und Komponentefertig
- prisma-migratorSchema und zugehörige Migrationfertig
Verifikation
- backend-verifiersauberer Start, keine fehlenden ProviderPASS
- frontend-verifierTypprüfung, Lint, BuildPASS
- e2e-testerbetroffene Abläufe im echten BrowserPASS
Merge
- mergewartet auf einen Menschenhält
Die Agentennamen stammen aus der Plattform, mit der auch diese Website gebaut wurde.
Läuft unbeaufsichtigt
- Den Code finden: parallele Leser kartieren die betroffenen Schichten, bevor etwas geschrieben wird.
- Die Änderung schreiben, ein Spezialist je Schicht, parallel wo sich die Schichten nicht überschneiden.
- Typprüfung, Lint und Build; den Backend-Start beobachten und auf Startfehler prüfen.
- Die Testsuite laufen lassen und die laufende Anwendung durch die betroffenen Abläufe steuern.
- Barrierefreiheit, responsives Verhalten und Seitenperformance gegen gemessene Budgets prüfen.
Wartet auf einen Menschen
- Jeder Merge. Kein Agent pusht eigenständig in einen geteilten Branch.
- Schemaänderungen und Datenmigrationen, die vor der Erzeugung geprüft werden, nicht danach.
- Alles, was die Produktion berührt: Deployments, Produktionsdaten, Force Pushes.
- Der Umfang. Zeigt sich eine Aufgabe größer oder riskanter als eingeschätzt, hält die Pipeline an und fragt nach.
- Die letzte Entscheidung zu jedem Review-Befund, auch ob ein markiertes Risiko akzeptiert wird.
Die Qualitätslatte
Was eine Änderung überstehen muss.
Verifikation hat einen harten Boden
Eine Codeänderung gilt nie als fertig ohne Build- und Lint-Prüfung der berührten Schichten. Backend-Änderungen müssen sauber starten. Dieser Boden steht in der Orchestrierungsdoktrin, sodass kein einzelner Lauf ihn überspringen kann.
Prüfungen folgen dem Befund, nicht der Gewohnheit
Welche Verifier laufen, ergibt sich aus der tatsächlichen Liste geänderter Dateien, und die schwerere Stufe wird von build-sensiblen Pfaden ausgelöst, nicht geraten. Genau das hält Gründlichkeit billig genug, um nicht verhandelbar zu sein.
Befunde müssen einen Skeptiker überstehen
Jeder Review-Befund geht an einen frischen Agenten, dessen einzige Aufgabe es ist, ihn zu widerlegen. Was sich nicht widerlegen lässt, bleibt; der Rest fällt weg, bevor ihn jemand liest. Das ist der Unterschied zwischen einem Review und einem lauten Scan.
Fehlschläge werden erst eingeordnet, dann behoben
Eine fehlgeschlagene Prüfung wird zuerst als Code- oder Umgebungsproblem eingeordnet. Umgebungsprobleme kommen nie in eine Reparaturschleife, sie werden mit Abhilfe gemeldet und der Lauf stoppt. Reparaturversuche sind gedeckelt, und eine wiederkehrende Ursache eskaliert, statt sich zu wiederholen.
Tests werden zum Bleiben geschrieben
Regressionstests entstehen als eingecheckte Spezifikationen im Testrunner des Projekts, nicht als Wegwerfprüfung innerhalb einer Sitzung. Was eine Korrektur bewiesen hat, bleibt im Repository und beweist sie weiter.
Nichts wird stillschweigend eingeschränkt
Wird die Abdeckung begrenzt, durch Stichprobe, Obergrenze oder eine ausgelassene Dimension, wird das berichtet. Ein Teilergebnis liest sich nie wie ein vollständiges.
Warum die Zeitpläne kürzer werden
Die Standards haben sich nicht bewegt. Die Kosten, sie einzuhalten, schon.
Jede dieser Prüfungen gab es auch in einem klassischen Team. Geändert hat sich, dass ihre Ausführung kein Kalenderproblem mehr ist. Reviews über fünf Dimensionen laufen gleichzeitig, statt auf einen freien Termin zu warten. Ein Testdurchlauf über ein Dutzend Seiten kostet einen Aufruf statt eines Nachmittags. Arbeit, die früher gebündelt wurde, weil sie teuer war, läuft heute bei jeder Änderung, weil sie es nicht mehr ist.
Das ist der ganze Trick, und deshalb geht das Tempo nicht vom Qualitätsbudget ab. Wenn Verifikation billig ist, steigt das vernünftige Maß daran, statt zu sinken.
Denselben Ablauf an einem echten Build ansehenZwei Methoden, zwei Fragen
Diese Seite ist unser Lieferablauf. Das unternehmensweite Modell wird separat veröffentlicht.
Was Sie gerade gelesen haben, ist die Art, wie wir unsere eigenen Produkte bauen: die Plattform, die Trennung zwischen dem, was unbeaufsichtigt läuft, und dem, was auf einen Menschen wartet, und die Latte, die jede Änderung nehmen muss. Eine ganze Organisation so arbeiten zu lassen, Rolle für Rolle, ist ein anderes Problem mit einer anderen Antwort. Diese veröffentlicht augmented.club vollständig, und das ist das Dokument für die Frage, wie das in Ihrem Unternehmen aussähe, statt wie wir unseres bauen.
Die veröffentlichte Methode lesenDieselbe Methode, vermittelt.
Engineering-Organisationen, die so arbeiten wollen, lernen es über augmented.club, unsere Weiterbildungsmarke.
Programme ansehen