Zum Inhalt springen
Lassen Sie jede Datenbank-Änderung als eigenes, lesbares und datiertes Skript entstehen, das Sie vor der Ausführung prüfen und freigeben. Es wandert kontrolliert von der Entwicklung über den Test bis in den Live-Betrieb, bei Bedarf auch zurück. Ihre Staging-Umgebung füllen Sie auf Knopfdruck, mit aktuellen Live-Daten oder mit Entwicklungsdaten.

Der agentische Teil

Ein Agent wendet jede offene Datenbank-Änderung im Zuge des Releases an und prüft sie im Anschluss ein zweites Mal, damit sich beim zweiten Durchlauf nichts mehr ändert. Bestätigt der zweite Lauf das Ergebnis nicht, lässt er das Release nicht weiterlaufen. Beim Befüllen der Staging-Umgebung gleicht er zusätzlich jede übertragene Zeile ab und meldet Vollständigkeit erst, wenn wirklich alles angekommen ist.

Hauptfunktionen

  • Bisher automatisch erzeugte Datenbank-Änderungen bleiben erhalten
  • Geordnete Skript-Sammlung je Dienst, mit Statusübersicht
  • Jede Änderung erst gegen die aktuelle Datenbank geprüft
  • Komplette Umgebungskopie oder nur die fehlenden Skripte
  • Wiederherstellung der Live-Datenbank ohne Anwendungsstopp
  • Reine Kopie direkt vom Server, ohne Neustart
  • Überschreiben einer genutzten Umgebung, Zugriff kurz freigegeben
  • Vollständige Übernahme mit Sicherung vorher, Zeilenabgleich danach
  • Jede Datenbank-Änderung zur Sicherheit zweimal angewendet

Einsatzszenarien

  • Bisher liefen Datenbank-Änderungen unkontrolliert direkt gegen die Live-Datenbank, ohne dass jemand sie vorher gegengelesen hatte. Jetzt entsteht aus jeder Änderung ein lesbares, datiertes Skript, das Sie vor der Ausführung prüfen und freigeben.
  • Ihre Staging-Umgebung soll die aktuellen Live-Daten zum Testen bekommen. Ein Klick füllt sie neu, wahlweise mit Live-Daten oder mit Entwicklungsdaten.
  • Vor einem Release muss feststehen, dass wirklich jede Zeile angekommen ist. Der Agent wendet jede offene Änderung an, prüft sie ein zweites Mal und lässt das Release nur weiterlaufen, wenn sich beim zweiten Durchlauf nichts mehr ändert.
  • Eine Änderung soll zurückgenommen werden. Sie wandert kontrolliert von Live über Test zurück in die Entwicklung.

Was wir für Sie bauen

  • Dienst- und Datenbanknamen, sowie Test- und Live-Paare
  • Datenbank-Server, Login und Passwort-Ablageort
  • Eingefrorene oder nie existierende frühere Auto-Änderungen
  • Produktivserver und -datenbanken, sowie Zugriffsregelung
  • Namen von Staging und Datenbank, sowie Anwendungs-Login
  • Datenbank-Änderungsskripte und ihre Prüfabfragen