> For the complete documentation index, see [llms.txt](https://docs.kiloiot.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kiloiot.io/kilo-docs-de/kilo-iot-server/rules-engine/builds-artifacts-and-deployment.md).
# Builds und Bereitstellung
Kilo IoT-Regel-Artefakte erstellen, benennen und bereitstellen — das Diagramm validieren, ein Artefakt erzeugen, dann mit der Verarbeitung beginnen.
Das Speichern einer Regel bewahrt deine Arbeit. Das Erstellen einer Regel validiert sie und erzeugt ein bereitstellbares Artefakt. Das Bereitstellen eines Artefakts startet die Regel und lässt sie ihre ausgewählte Sensor- oder Triggerquelle verarbeiten. Das sind bewusste, separate Schritte – die Plattform führt niemals Automatisierungslogik aus, die nicht ausdrücklich erstellt und bereitgestellt wurde.
Diese Trennung ist für Produktionsumgebungen entscheidend. Sie bedeutet, dass du eine Regel über mehrere Bearbeitungssitzungen hinweg iterieren kannst, ohne das aktuell laufende System zu beeinflussen. Wenn du mit dem Entwurf zufrieden bist, erstellst du ihn, und wenn du bereit bist, ihn live zu schalten, stellst du ihn bereit.
## Eine Regel erstellen
### Einen Build starten
Klicke im Regelereditor auf die **Erstellen** Schaltfläche in der Kopfzeile. Die Seitenleiste mit den Build-Ergebnissen öffnet sich auf der rechten Seite des Editors.
### Die Seitenleiste mit den Build-Ergebnissen
Die Seitenleiste ist ein Formular, in dem du den Build benennst und mit Anmerkungen versiehst, bevor du ihn erstellst:
| Feld | Beschreibung |
| ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | Ein erforderlicher Name für dieses Build-Artefakt. Wähle etwas, das die Änderung kennzeichnet – zum Beispiel „Aktualisierung des Feuchtigkeitsgrenzwerts“ oder „Eskalationszweig hinzugefügt“. |
| **Kommentar** | Ein optionales Textfeld für zusätzlichen Kontext. Nutze es, um zu vermerken, warum der Build erstellt wurde, was sich seit dem letzten Build geändert hat oder welche Bereitstellungsanweisungen es für dein Team gibt. |
Am unteren Rand der Seitenleiste:
* **Speichern und erstellen** — Speichert den aktuellen Regelzustand als neue Version und erstellt daraus anschließend ein Build-Artefakt.
* Ein Link zur Artefaktliste: *„Du kannst Container in der Artefaktliste verwalten.“* Klicke darauf, um direkt zur Registerkarte „Artefakte“ zu navigieren.
### Build-Ergebnisse
**Bei Erfolg:** Eine Benachrichtigung bestätigt *„Build erfolgreich erstellt“* und die Seitenleiste schließt sich. Das Build-Artefakt erscheint in der Registerkarte „Artefakte“ und ist bereit für die Bereitstellung.
**Bei einem Fehler:** Wenn der Build auf Validierungsfehler stößt – etwa ungültige CEL-Ausdrücke, fehlende Verbindungen oder strukturelle Probleme im Diagramm – wird die Fehlermeldung direkt in der Seitenleiste angezeigt. Behebe die gemeldeten Probleme im Editor und versuche den Build erneut. Siehe [Fehlerbehebung](/kilo-docs-de/kilo-iot-server/rules-engine/troubleshooting.md) für eine vollständige Liste der Build-Fehler und deren Behebung.
### Was ein Build macht
Der Build-Schritt:
1. Speichert die aktuelle Regel als neue Version (damit der gebaute Zustand immer in der Versionshistorie erfasst wird)
2. Validiert das gesamte Diagramm: Struktur, Verbindungen, Knotenkonfigurationen und alle CEL-Ausdrücke
3. Erzeugt ein Artefakt – ein bereitstellbares Paket, das die validierte Regellogik enthält
## Die Registerkarte „Artefakte“
### So gelangst du dorthin
Von der Seite der Rules Engine unter `/rules`, klicke auf die **Registerkarte „Artefakte“** (die zweite Registerkarte, zwischen „Regeln“ und „Papierkorb“).
### Suche
Eine Suchleiste oben in der Registerkarte filtert Artefakte nach dem Regelnamen. Gib etwas ein, um die Liste einzugrenzen, wenn du viele Regeln verwaltest.
### Artefakt-Gruppierung
Artefakte werden nach Regelddefinition gruppiert. Jede Regel mit mindestens einem Build erscheint als aufklappbare Zeile mit Regelname und Beschreibung. Klicke auf eine Regelleiste, um sie zu erweitern und alle Builds dieser Regel anzuzeigen.
### Leerer Zustand
Wenn noch keine Builds vorhanden sind, zeigt die Registerkarte: *„Keine Artefakte“* mit der Meldung *„Artefakte werden hier erscheinen, wenn Regeln sie erzeugen.“*
### Build-Details
Jede aufgeklappte Gruppe listet einzelne Builds mit den folgenden Spalten auf:
| Spalte | Beschreibung |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Build-Name** | Der Name, den du dem Build gegeben hast. Farbcodiert nach Status: Grün für Laufend, Orange für Gestoppt, Rot für Erzwungen gestoppt. |
| **Quelle** | Ein Link, der die schreibgeschützte Regelansicht öffnet, damit du die Regeldefinition prüfen kannst, die dieses Artefakt erzeugt hat. |
| **Datum & Uhrzeit** | Wann der Build erstellt wurde, formatiert als „dd MMM yyyy, HH:mm“ |
| **Benutzer-ID** | Das Teammitglied, das den Build erstellt hat. In der aktuellen Benutzeroberfläche wird hier typischerweise der aufgelöste Benutzername zusammen mit der Benutzer-ID angezeigt. |
| **Kommentar** | Der während des Builds eingegebene Kommentar. Klicke zum Inline-Bearbeiten – drücke Enter zum Speichern oder Escape zum Abbrechen. |
### Artefaktstatus
| Status | Farbe | Bedeutung |
| ---------------------- | ------ | -------------------------------------------------------------------------------------------------------------------------------------------- |
| **Laufend** | Grün | Das Artefakt ist bereitgestellt und wartet auf seinen ausgewählten Sensor oder Trigger-Quelle |
| **Gestoppt** | Orange | Das Artefakt wurde manuell gestoppt. Es kann erneut bereitgestellt werden. |
| **Erzwungen gestoppt** | Rot | Das System hat das Artefakt aufgrund anhaltender Ausführungsfehler automatisch gestoppt. Siehe [Notfall-Sicherung](#emergency-safety) unten. |
## Ein Artefakt bereitstellen
Die Bereitstellung startet ein erstelltes Artefakt, sodass es Live-Sensordaten in Echtzeit verarbeitet.
### So bereitstellst du es
1. Öffne die **Registerkarte „Artefakte“** Registerkarte auf der Seite der Rules Engine.
2. Erweitere die Regelgruppe, die den Build enthält, den du bereitstellen möchtest.
3. Klicke auf **Bereitstellen** in der Build-Zeile.
Der Artefaktstatus ändert sich zu **Laufend** (grün). Die Regel wertet nun aktiv jede neue Messung ihres angebundenen Sensors aus und führt die Automatisierungslogik aus.
### Bereitstellungsbeschränkungen
* Nur **ein Build pro Regel** kann gleichzeitig ausgeführt werden.
* Wenn eine Regel bereits ein laufendes Artefakt hat und du einen anderen Build bereitstellst, stoppt die Plattform das laufende Artefakt automatisch und startet das neue in einem einzigen Vorgang. Es ist nicht nötig, das laufende Artefakt vorher zu stoppen – der Wechsel wird für dich übernommen.
## Eine laufende Regel stoppen
Das Stoppen ist eine bewusste Pause-Aktion – verwende sie, wenn du möchtest, dass eine Regel auf ihre ausgewählte Quelle nicht mehr reagiert, ohne eine andere Version bereitzustellen.
### So stoppst du es
1. Öffne die **Registerkarte „Artefakte“** Registerkarte.
2. Finde das laufende Artefakt (grüner Status).
3. Klicke auf **Stoppen**.
Der Status ändert sich zu **Gestoppt** (orange). Die Regel akzeptiert sofort keine neuen Starts mehr. Sensoren melden weiterhin Werte und Trigger überwachen weiter, aber die gestoppte Regel wird aus keiner der beiden Quellen ausgeführt.
Ein gestopptes Artefakt kann jederzeit erneut gestartet werden, indem du **Bereitstellen** erneut klickst.
## Ein Build-Artefakt löschen
Um ein Build-Artefakt zu entfernen, das du nicht mehr benötigst:
1. Öffne die **Registerkarte „Artefakte“** Registerkarte.
2. Finde das zu löschende Artefakt. Es muss im Status **Gestoppt** oder **Erzwungen gestoppt** sein – du kannst kein laufendes Artefakt löschen.
3. Klicke auf **Löschen** in der Build-Zeile.
Laufende Artefakte müssen gestoppt werden, bevor sie gelöscht werden können.
## Notfall-Sicherung
Die Plattform überwacht die Ausführungsgesundheit jeder laufenden Regel. Wenn eine Regel während der Ausführung anhaltende Fehler aufweist – zum Beispiel wurde ein referenzierter Sensor gelöscht, ein Ausdruck schlägt bei Live-Daten kontinuierlich fehl oder ein Anreicherungsziel ist dauerhaft nicht verfügbar – stoppt das System die Regel automatisch, um Kaskadenfehler zu verhindern.
Wenn das passiert:
* Der Artefaktstatus ändert sich zu **Erzwungen gestoppt** (rot) in der Registerkarte „Artefakte“.
* Die Regel reagiert nicht mehr auf neue Sensormessungen oder Trigger-Aktivierungen.
* Von dieser Regel werden keine weiteren Alarme oder Benachrichtigungen erzeugt.
### Wiederherstellung nach einem erzwungenen Stopp
1. **Untersuche die Ursache.** Überprüfe die Regellogik im Editor. Prüfe, ob referenzierte Sensoren noch aktiv sind, Ausdrücke für die tatsächlichen Datenstrukturen gültig sind und Anreicherungsziele erreichbar sind.
2. **Behebe das Problem.** Bearbeite die Regel, um die Ursache zu beseitigen.
3. **Erstelle eine neue Version.** Erzeuge aus der korrigierten Regel ein frisches Build-Artefakt.
4. **Stelle den neuen Build bereit.** Starte das korrigierte Artefakt in der Registerkarte „Artefakte“.
Stelle das erzwungen gestoppte Artefakt nicht einfach erneut bereit, ohne das zugrunde liegende Problem zu beheben – dieselben Fehler treten sonst erneut auf und die Regel wird wieder gestoppt.
## Bewährte Vorgehensweisen
* **Benenne Builds nach der enthaltenen Änderung.** Wenn du während eines Vorfalls um 3 Uhr morgens die Registerkarte „Artefakte“ durchsiehst, ist „Feuchtigkeits-Fallback hinzugefügt“ hilfreicher als „Build 7“.
* **Füge Builds Kommentare hinzu.** Kommentare können nach der Erstellung bearbeitet werden, sodass du Builds mit Bereitstellungsnotizen, Vorfall-Referenzen oder Rollback-Anweisungen versehen kannst.
* **Stelle direkt über den laufenden Build bereit.** Pro Regel läuft immer nur ein Build gleichzeitig, und die Bereitstellung eines neuen ersetzt ihn in einem einzigen Vorgang – es ist nicht nötig, das aktuelle Artefakt vorher zu stoppen. Verwende „Stoppen“, wenn die Regel ganz aufhören soll zu evaluieren, nicht als Schritt vor der Bereitstellung.
* **Behandle erzwungene Stopps als Vorfälle.** Eine erzwungene gestoppte Regel bedeutet, dass die Live-Überwachung für diese Regel beendet wurde. Untersuche und behebe die Ursache umgehend.
* **Aus einer sauberen Version erstellen.** Wenn du an einer Regel iteriert hast, speichere sie vor dem Erstellen manuell und benenne die Version. So wird sichergestellt, dass das Build-Artefakt in der Historie einer eindeutig identifizierten Version zugeordnet ist.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.kiloiot.io/kilo-docs-de/kilo-iot-server/rules-engine/builds-artifacts-and-deployment.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
