Software ist kein Handwerk mehr. Sie ist eine Technik.

Vom Handwerk zur Technik

Ein Handwerk wird zur Technik, sobald sich seine Schritte aufschreiben, wiederholen und prüfen lassen. Software hat diese Linie gerade überschritten — und sobald etwas Technik ist, schlägt die Fabrik die Werkstatt.

Die Linie, Station für Station

Vom ersten Training bis zur laufenden Software, Station für Station. Jede ist markiert: Live läuft heute; Kommt bauen wir als Nächstes.

1. 01Live

   Es beginnt mit Training

   Vor der Linie kommen Menschen: Beraterinnen und Berater lernen, KMU zu KI zu beraten, und schulen dann die Teams ihrer Kunden mit einem White-Label-Kurs, dessen letzter Schritt zu einem neuen Projekt oder neuen Anforderungen wird.

   Mehr erfahren →

2. 02Live

   Anforderungen zuerst

   Nichts wird aus einem vagen Briefing gebaut. Aus einem Gespräch werden Anforderungen, jede mit ihren Akzeptanzkriterien, und die Linie baut nur, was angenommen wurde.

3. 03Live

   Eine durchgehende Linie

   Sobald seine Anforderungen angenommen sind, geht ein Workstep ohne Klick an einen Coding-Agenten: ein Build pro Projekt nach dem anderen, in Reihenfolge. Jeder Workstep verlässt die Linie als Pull Request.

4. 04Live

   Prüftore bei jeder Änderung

   Jeder Pull Request durchläuft die CI und die Security-Scans des Projekts, dann ein KI-Security-Review, das im Zweifel sperrt: kein Urteil, kein Merge, und der Merge ist an genau die geprüfte Version gebunden. Ein Wächter auf dem Main-Branch verweigert das Deployment von allem, was an den Prüftoren vorbeiging.

5. 05Live

   Nachweis pro Kriterium

   Jedes Akzeptanzkriterium bekommt seinen eigenen Testlauf aus der CI, aufgezeichnet nach dem Merge der letzten Änderung der Anforderung, und eine Anforderung gilt erst als verifiziert, wenn alle bestanden sind. Ein Kriterium, das ein Mensch prüft, zeigt „Prüfung durch Mensch ausstehend“, bis es abgezeichnet ist. Das Wort des Agenten zählt nie.

6. 06Live

   Test zuerst, von Rot zu Grün

   Der Test für jedes Akzeptanzkriterium wird zuerst geschrieben und muss in der CI fehlschlagen, bevor der Code ihn bestehen lässt. Vor dem Merge prüft das Prüftor, dass der Test jedes Kriteriums von Rot zu Grün ging und unterwegs nicht geändert wurde; die Anforderung verlinkt beide Läufe.

7. 07Live

   Eine Reparaturschleife

   Lehnen CI oder Security-Review eine Änderung ab, gehen die Befunde an dieselbe Agenten-Sitzung zurück, die sie im selben Pull Request behebt, und jedes Prüftor läuft erneut. Standardmäßig höchstens zwei Reparaturen; danach übernimmt ein Mensch.

8. 08Live

   Normteile

   Jede App startet aus der Fabrikvorlage, mit den gelösten Problemen schon drin: Anmeldung, Mandanten und Rollen, Rechtsseiten, Layout. Einmal gebaut, im Betrieb gehärtet, nie neu gebaut.

9. 09Live

   Die Fabrikbibliothek bei jedem Schritt

   Wird ein Workstep-Plan freigegeben, bekommt jeder Workstep die Normteile, die das Design gewählt hat. Worksteps, die die Datenbank oder andere sensible Bereiche berühren, werden mit den Security- und Datenbank-Guidelines der Bibliothek gebaut, und das Build-Protokoll nennt, welche und warum.

10. 10Live

    Vom Release zu Live

    Ein veröffentlichtes Release bringt eine gehostete App in Produktion: zuerst die Datenbankmigrationen, der Reihe nach, mit Stopp beim ersten Fehler; dann der Build. Das Release zeigt Live erst, wenn die Live-Adresse ihn ausliefert.

11. 11Live

    Ein ehrlicher Stand

    Bis alles im Umfang released ist, zeigt ein Projekt „Im Bau — 3 von 6 Worksteps ausgeliefert“, und erst danach „Live“. Eine neue App zeigt Besuchern „Demnächst“ und ihren angemeldeten Nutzern die Bauschritte; eine Seite „Was in der App steckt“ listet die mitgelieferten Teile, das Gebaute und das, was noch kommt.

12. 12Live

    Alles protokolliert

    Jeder Build-Job, jedes Release-Deployment und jede Änderung, die den Main-Branch an den Prüftoren vorbei erreicht hat, wird festgehalten. Unsere Operator-Aktionen landen in einem Audit-Log, das nur angehängt werden kann.

13. 13Live

    Begrenzte Schlüssel, EU-Hosting

    Für Apps, die wir hosten, bekommt jeder Build ein kurzlebiges Token für genau dieses eine Repository, das am Ende des Builds gelöscht wird. Ihre Modell-Schlüssel bleiben bei Ihrem PP Orchestrator. Cloud-Instanzen laufen in Deutschland (EU).

„Live“ heißt: in einem Product-Printer-Release ausgeliefert und auf unseren verwalteten Instanzen in Betrieb. Eine Station wechselt von „Kommt“ zu „Live“ erst, wenn ihr Release dort läuft.