Engineering-Praxis
Wie ForgeIEC gebaut wird — mit Toren, die jede Änderung bestehen muss, und Tests, die das ausgelieferte Paket prüfen. Jede Zahl auf dieser Seite nennt ihr Messdatum und ihre Quelle.
- 13Qualitätstore je Änderungtongs-core,
tools/qm.sh, gezählt am 22.10.2026 - ≈ 96 %Zeilenabdeckung, Tor ab 90 %tongs-core,
cargo llvm-cov, gemessen 22.10.2026 - 5abhängige Repositories bei jedem Push mitgebautRückwärtsprüfung,
.forgejo/workflows/qm.yml, 22.10.2026 - 18 + 10Paket-Slots in der Linux-CI (Runtime + Studio)
linux.ymlvon anvil und Studio, gezählt 22.10.2026
Dreizehn Tore, lokal und in der CI dieselben
Das Skript tools/qm.sh im Kern-Repository tongs-core führt alle Tore aus — auf dem Entwicklerrechner genauso wie in der CI bei jedem Push und jedem Pull-Request. Alle Tore laufen durch; ein rotes verdeckt die anderen nicht. Wer ein Tor ändert, ändert es im Skript, nicht im Workflow.
| Tor | Was es prüft |
|---|---|
| format | einheitliche Formatierung (cargo fmt --all --check) |
| clippy | statische Analyse, jede Warnung ist ein Fehler (-D warnings) |
| tests | alle Tests des Arbeitsbereichs mit allen Features |
| docs | API-Dokumentation baut, Warnungen sind Fehler |
| deploy | deploy.sh und deploy.fish gleichen den Vorlagen |
| machete | keine ungenutzte Abhängigkeit |
| unsafe | jede Crate verbietet unsafe; nur das Anvil-Modul von tongs-runtime darf es; dazu ein cargo geiger-Bericht |
| lock | alle iceoryx2-Pakete in Cargo.lock tragen dieselbe Version |
| audit | bekannte Sicherheitslücken (RustSec); Lücken sind Fehler |
| deny | Lizenzen, doppelte Versionen und Quellen der Abhängigkeiten (deny.toml) |
| msrv | der Code baut mit der zugesagten Mindestversion von Rust (1.88) |
| abdeckung | Zeilenabdeckung mindestens 90 % (cargo llvm-cov) |
| rueckwaerts | jede Zange (Bus-Brücke) baut noch gegen den neuen Stand des Kerns |
Quelle: tongs-core/tools/qm.sh und README.md, Stand 22.10.2026. Die Werkzeuge haben feste Versionen und liegen in der CI in einem vorgebauten Container-Image.
Eine Änderung am Kern bricht nichts still
Auf tongs-core bauen fünf Bus-Brücken auf: Modbus TCP, Modbus RTU, EtherCAT, EtherNet/IP und PROFIBUS — jede in einem eigenen Repository. Die CI des Kerns holt alle fünf und baut sie gegen den Stand des Laufs (cargo check --locked). Ein API-Bruch zeigt sich im Pull-Request des Kerns, nicht Tage später im nächsten Lauf einer Brücke.
Prüfen, ob die Tests etwas prüfen
Abdeckung sagt nur, welche Zeilen ein Test berührt. Mutationstests (cargo mutants) verändern den Code gezielt und schauen, ob ein Test das bemerkt. Für jeden Push sind sie zu langsam — rund 1 400 Mutanten im Arbeitsbereich —, deshalb laufen sie wöchentlich in der Nacht auf Sonntag und von Hand, als Bericht, nicht als Tor.
Quelle: tongs-core/.forgejo/workflows/qm-nightly.yml, Stand 22.10.2026.
Getestet wird das, was ausgeliefert wird
Unit-Tests prüfen den Code im Baum. Der Systemtest tools/system-test.sh prüft das installierte Paket: Er startet den Anvil-Server (anvild) aus dem neuesten Paket des apt-Repositorys mit einer Beispiel-Zange — isoliert, mit eigener Registry, eigenem Speicher und eigenem Port, ohne einen laufenden Dienst der Maschine zu berühren.
Geprüft wird: Der Master vergibt eine Adresse, die Zange meldet sich online, ein Protokoll ohne Programm wird gemeldet, Status und Prozessdaten folgen der Simulation — und die Zange beendet sich selbst, wenn der Anvil-Server getötet wird.
Beispiel · tongs-core Issue #26
Eine Zange lebte weiter, nachdem anvild getötet war
- Gefunden
- vom Systemtest: Nach
kill -KILLdes Anvil-Servers lief der Prozess der Zange 15 Sekunden und länger weiter — ohne Bus. - Ursache
- Das Log lief über eine Pipe zum Anvil-Server. Mit ihm war die Pipe tot; die Log-Zeile vor dem Beenden schlug fehl, und die Aufgabe, die das Beenden auslösen sollte, starb mit.
- Behebung
- Erst handeln, dann loggen; eine gebrochene Pipe wird ignoriert.
- Seitdem
- ist der Systemtest der Regressionstest dafür. Issue geschlossen.
Regeln, die das Projekt tragen
Ein Projekt dieser Größe bleibt nur beherrschbar, wenn jede Entscheidung auffindbar ist — auch für jemanden, der neu dazukommt.
Spezifikationen mit Belegen
Protokolle und Modelle stehen in versionierten Papieren (z. B. tongs-bus-v1, tongs-parameter-v1, diag-model-v1). Weicht der Code ab, entscheidet der gemessene Stand; das Papier bekommt einen Korrektur-Kasten oben und eine Korrekturnotiz an der Stelle.
Gutachten mit Befundformat
Prüfungen von Papieren, Verträgen und Architekturentscheidungen folgen einem festen Format: Fakt (gemessen, mit Befehl), Annahme, Auswirkung und was nicht die Ursache ist. Eine reine Papierprüfung genügt nicht.
Das Wiki ist der Einstieg
Neue Entwickler beginnen mit der Seite „Architecture“ des Kern-Wikis: Prozesse, Repositories, Abhängigkeitsbaum der Crates, Typen und „Where do I change what?“. Das Wiki beschreibt nur den aktuellen Stand, ohne Historie.
Englisch in Code und Prozess
Kommentare, Commit-Nachrichten, Issues und Wiki-Seiten sind englisch — damit jede Entwicklerin und jeder Entwickler mitlesen kann. Die Webseite gibt es auf Deutsch und Englisch.
Eine Regel, ein Ort
Jede Regel steht genau einmal: Ein Qualitätstor wird in qm.sh geändert, nicht im CI-Workflow; die Lizenzgrenze steht in LICENSING.md; Werkzeugversionen in einer einzigen Datei.
Commits mit Begründung, Fehler als Issue
Ein Commit je Änderung, mit dem Warum im Text. Jeder unterwegs gefundene Fehler wird sofort ein Issue — auch wenn er nicht gleich behoben wird. Offen am 22.10.2026: 65 Issues im Studio, 21 in anvil, 40 in hearth-studio, 3 in tongs-core.
Signierte Pakete aus einer automatisierten CI
Die Runtime (anvil) wird in 18 Slots gebaut: Debian 12 und 13, Ubuntu 22.04 und 24.04 je für amd64, aarch64 und armhf, dazu AlmaLinux, Rocky Linux und RHEL 8 und 9 für amd64. Das Studio in 10 Slots: Debian 12 und 13, Ubuntu 24.04, AlmaLinux 9 und Fedora 44 je für amd64 und aarch64. Gepackt wird als .deb und .rpm.
Die Pakete kommen signiert in die Repositories apt.forgeiec.io und rpm.forgeiec.io — Installation siehe Download. Für das Studio gibt es zusätzlich eine Windows-CI mit eigenem Windows-Runner und Inno-Setup-Installer.
Quelle: .forgejo/workflows/linux.yml und windows.yml von anvil und Studio, gezählt am 22.10.2026.
Dokumentiert, nicht nur behauptet
Für die EU-Cyberresilienzverordnung (CRA) gibt es eine öffentliche Sicherheitsseite mit security.txt nach RFC 9116 und einer Richtlinie zur koordinierten Offenlegung von Schwachstellen.
Die Lizenzlage wird gemessen: Ein Provenienz-Audit vom 22.10.2026 hat 2 618 Dateien zeilenweise per git blame geprüft und hält fest, woher der Code stammt. In der Rust-Welt prüft das Tor deny die Lizenzen jeder Abhängigkeit bei jedem Push.
KI-gestützt entwickelt — und gemessen geprüft
ForgeIEC wird mit KI-Werkzeugen entwickelt, und das steht offen in der Historie: Die meisten Commits tragen eine Co-Authored-By-Zeile. Im Studio-Repository sind es 91 % der eigenen Commits (1 821 von 1 999 Commits des Autors auf dem Zweig development seit dem 28.02.2026, Merges eingeschlossen; gemessen am 22.10.2026).
Der Autor gibt die Richtung vor, entscheidet und prüft durch Messung: Qualitätstore, Gutachten, Systemtests und Berichte mit Quellenangaben. Was ein KI-Werkzeug beiträgt, wird behandelt wie jeder andere Beitrag — es muss dieselben Tore bestehen.
Mehr über den Entwickler
Wer hinter ForgeIEC steht und welche Aufgabe er sucht.