Deployment-Pipeline: Vom Code zur kontrollierten Bereitstellung

Der Data Integrity Deployment Cycle (DIDC) ist der zentrale Kernprozess der omniSuite für die sichere Bereitstellung von Änderungen. Er transformiert das oft riskante Deployment in einen strukturierten, kontrollierbaren und vollständig dokumentierten Prozess. Jede Änderung wird automatisch erfasst, versioniert und in einem Deployment-Paket zusammengeführt.

Vor der eigentlichen Bereitstellung erfolgt eine systemweite Validierung aller betroffenen Objekte und Abhängigkeiten. Das System prüft Trigger, Skripte, APIs, Tabellen und Felder auf Konsistenz, Vollständigkeit und Integrität. Die Validierung ist kein optionaler Schritt, sondern integraler Bestandteil des Bereitstellungsprozesses.

Über den Menüpunkt „System-Integrität“ lassen sich sämtliche SQL-Skripte, APIs, Trigger und gespeicherte Prozeduren automatisiert auswählen und prüfen. Das System führt Syntax- und Logikprüfungen durch, identifiziert veraltete oder nicht vorhandene Attribute und liefert eine zentrale Übersicht über mögliche Fehlerquellen — vergleichbar mit einem Linter für die gesamte Anwendungslandschaft.

Ergänzend können Entwickler einzelne SQL-Skripte, APIs, Trigger und gespeicherte Prozeduren gezielt für eine automatische Prüfung auswählen. Der Vorteil: schnelles Feedback auf Einzelobjektebene, ohne den Overhead einer vollständigen Systemprüfung.

Beide Mechanismen sind komplementär. Die dezentrale Prüfung dient der laufenden Entwicklungsarbeit — schnelles Feedback bei einzelnen Änderungen. Die zentrale Prüfung ist der Gate-Check vor dem Deployment: Sie stellt sicher, dass alle Änderungen im Zusammenspiel konsistent sind.

Vor jeder Änderung führt das System eine Impact-Analyse durch. Entwickler sehen auf Knopfdruck, welche Masken, Skripte oder Prozeduren von einer Anpassung betroffen sind. Die Analyse arbeitet auf Attributebene: Verwendung von Attributen, Tabellen, Masken und Beziehungen in Masken, Skripten, Triggern und Prozeduren wird vollständig analysiert. Konflikte und Inkonsistenzen werden hervorgehoben.

Die Plattform ermöglicht die vollständige Rückverfolgbarkeit auf Attributebene. Entwickler können nachvollziehen, wo ein Attribut in Masken referenziert wird, welche Skripte darauf zugreifen und welche Trigger es verwenden. Diese Transparenz macht Refactoring planbar und reduziert das Risiko unentdeckter Abhängigkeiten.

Die omniSuite unterstützt das Testen in isolierten Daten-Sandboxen. Dies erlaubt realistische Testszenarien mit isolierten Daten, ohne die Integrität produktiver Geschäftsprozesse zu gefährden. Abhängigkeiten zwischen Masken, Skripten und Datenstrukturen werden automatisch erkannt und mitgetestet.

Ja, die omniSuite bietet eine Echtzeit-Entwicklungsumgebung. Konfigurierte Elemente und Code-Erweiterungen können unmittelbar nach ihrer Erstellung direkt im System ausgeführt werden — ohne Deployment-Verzögerung, Medienbruch oder externe Testumgebung. Die integrierten Syntax- und Logikprüfungen greifen sofort.

Der Übergang zwischen Umgebungen erfolgt über Systemobjektgruppen. Diese Gruppen bündeln Tabellen, Masken, Skripte und deren Abhängigkeiten. Der Export erfolgt als XML-Datei. Beim Import steuert das System den Prozess so, dass keine Inkonsistenzen entstehen und die korrekte Übernahmereihenfolge automatisch eingehalten wird.

Das System führt beim Import einen automatischen Abgleich der Systemobjekte im Quell- und Zielsystem durch. Es identifiziert Änderungen, fügt neue Objekte hinzu und erkennt Abhängigkeiten zwischen den Objekten selbstständig. Konflikte werden erkannt und zur Auflösung vorgelegt. Die automatische Reihenfolgebestimmung verhindert, dass ein Import an einer fehlenden Abhängigkeit scheitert.

Jede Änderung wird lückenlos in der Änderungsdokumentation protokolliert. Festgehalten werden der Grund der Änderung, eine fachliche Zweckbeschreibung, der Zeitpunkt sowie der Urheber. Die Dokumentation erfolgt auf zwei Ebenen: auf Ebene einzelner Systemelemente und zentral in Systemobjektgruppen. Damit ist nicht nur nachvollziehbar, was geändert wurde, sondern auch warum.

Ja, durch die strukturierte Paketierung und Dokumentation ist ein Rollback auf Knopfdruck vorgesehen. Dies senkt die Mean Time to Recovery (MTTR) deutlich. Da jede Version eines Deployment-Pakets gespeichert bleibt, können Entwickler gezielt auf einen definierten Zustand zurücksetzen, ohne das gesamte System zurückzurollen.

Ja, der DIDC unterstützt manuelle Freigaben. Änderungen können vor dem endgültigen Deployment gezielt von Entwicklern oder Fachanwendern geprüft und explizit freigegeben werden. Die Freigabe kann granular konfiguriert werden — etwa getrennt nach Umgebung oder nach Art der Änderung.

Das Event History Tracking erfasst jede Änderung an einem Informationsobjekt als eigenständiges Event in dedizierten Historientabellen. Die Historisierung ist auf Attributebene konfigurierbar: Für jedes Attribut wird festgelegt, bei welcher CRUD-Operation die Änderung protokolliert wird. Die Generierung der Historientabellen und der zugehörigen Trigger erfolgt vollautomatisch nach der Konfiguration.

Die granulare Konfiguration bedeutet konkret: Attribut A kann bei Create und Update historisiert werden, Attribut B nur bei Update und Delete, Attribut C nur bei Create. Separate Historientabellen ermöglichen zudem eine optimierte Abfrageleistung. Die Trigger-Funktionalität wird bei jeder Konfigurationsänderung automatisch angepasst — manuelles Scripting ist nicht erforderlich.

Die State Tracking Engine dokumentiert Zustandswechsel in dedizierten Zustandstabellen. Pro Objekt können mehrere Zustandstabellen angelegt werden. Diese Trennung ist architektonisch relevant: Unterschiedliche Zustandsdimensionen werden unabhängig voneinander verwaltet, was die Komplexität bei Deployments reduziert.

Zustandswechsel können automatisch Folgeereignisse auslösen. Die Konfiguration erfolgt über Ereignisdefinitionen mit spezifischen Bedingungen: nur bei bestimmten Zustandsübergangskombinationen, nur bei bestimmten neuen oder alten Zuständen. Als Ereignistypen stehen das Löschen von Beziehungen und die Ausführung gespeicherter SQL-Prozeduren mit dynamischen Parametern zur Verfügung.

Durch die Trennung in separate Zustandstabellen wird jede Dimension eigenständig verwaltet: eigene Trigger, eigene Ereignisdefinitionen, eigene Dokumentation. Ändert sich die Zustandslogik für den Bearbeitungsstatus, bleibt die Lebenszyklus-Tabelle unangetastet. Für Deployments reduziert das die Blast Radius einer Änderung erheblich.

Die gesamte Deployment-Logik basiert auf der Policy-Architektur und dem E-C-A-Gerüst. Da alle Regeln und Abhängigkeiten formal beschrieben und maschinenlesbar vorliegen, bildet dies das Fundament für zukünftige KI-gestützte Prozesssteuerungen und automatisierte Tests. KI-Agenten können die formal beschriebenen Regeln lesen, validieren und für Optimierungen nutzen.