Wer Software entwickelt – sei es mit den gängigen Entwicklungssprachen und -umgebungen – sollte Wert auf eine Versionierung des Quellcodes legen. Wie sieht das Ganze jedoch aus, wenn man das Gleiche bei einer DWH-Entwicklung auf einer Datenbank mit dem Oracle Warehouse Builder machen möchte? Also wie versioniert man die gesamten Objekte, die in einem OWB-Repository gespeichert sind? Eine Versionierung direkt sieht der OWB leider nicht vor.
Eine Möglichkeit besteht, in dem man manuell die Metadaten exportiert und die entsprechende MDL-Datei in ein Versionierungssystem wie SubVersion, CVS oder GitHub eincheckt. Selbst bei kleineren OWB-Projekten ist das manuelle Verfahren sehr aufwendig und es stellt an die OWB-Entwickler ein hohes Maß an Organisation und Disziplin. Eine direkte Versionierung der Metadatenobjekte ist im OWB nicht möglich! Daher besteht keine Kontrolle über den Status von Mappings, PL/SQL-Routinen oder abhängigen Objekten wie Tabellen oder Views. Die Folge ist, dass die Organisation von Releases sehr komplex ist und die Mehrfachbearbeitung an einen Objekt nicht ausgeschlossen werden kann. Teamwork in gemeinsamen Projekten ist sehr aufwendig, da alle Informationen manuell beschafft und dokumentiert werden müssen.
Die Lösung – VCR4OWB (Version Control und Releasemanagement für den OWB)
Der auf Java basierte Adapter VCR4OWB ermöglicht dem OWB-Entwickler Änderungen direkt aus dem Designer heraus releasebezogen im Versionsmanagement (z.B. Subversion) zu speichern! Detailänderungen sind verfolgbar und Projekte im Team sind einfacher zu bearbeiten und zu organisieren. Über das Versionmanagement lassen sich damit auch einzelne Objektversionen gezielt auswählen und über VCR4OBW zuverlässig wieder bereitstellen.
Installation des Adapters VCR4OWB
Der Adapter an sich ist nichts anders als ein Expert. Nachdem die Metadaten importiert sind, steht der Expert im OWB-Designer zur Verfügung und der OWB-Entwickler kann ihn in das Kontext-Menü an jedem beliebigen OWB-Projektknoten hinterlegen:
Konfiguration des Adapters VCR4OWB
- verfügbares Versionsmanagement auf einem zentralen Server (im Beispiel SVN-Server)
- erstelltes SVN Repository
- Benutzer und/oder Gruppen für den Zugriff auf die SVN-Repositories
Eine grundlegende SVN-Struktur unter Verwendung von VisualSVN Server (Link) kann wie folgt aussehen:
Wichtig an der Stelle: das SVN-Projekt (DODWH) und das OWB-Projekt (DODWH) müssen von der Namensgebung identisch sein!
Die URL gibt an, wie der SVN-Server mit dem entsprechenden Repository zu erreichen ist
- Der Zugriff wird über den Benutzer und das Passwort hergestellt
- Mit der Schaltfläche Connect wird die Verbindung zum SVN-Server gerpüft
- Mit Save wird die Konfiguration gespeichert
- Subproject Path und Release Path entsprechen der hinterlegten SVN-Projektstruktur (siehe Bild oben) und können frei gewählt werden
Objektversioniertes Arbeiten mit dem OWB
Ein erstes Beispielszenario:
1. Der Benutzer A erstellt ein neues Mapping MAP_JOBS und aktualisiert das SVN-Repository.
- Das Mapping wird im OWB-Designer markiert und der Adapter wird über das Kontextmenü aufgerufen.
- VCR4OWB erkennt, dass es im SVN-Repository noch kein Objekt MAP_JOBS gibt und der Status für dieses Mapping wird auf neu (grünes Pluszeichen) gesetzt:
Über die Schaltfläche Commit wird der Check-In-Vorgang für das neue Mapping in dem Versionsmanagement gestartet. Vor dem eigentlichen Check-In muss zwingend eine aussagekräftige Kommentierung hinzugefügt werden:
2. Der Benutzer A verändert das Mapping MAP_JOBS, indem er einen neuen Filter hinzufügt.
- Aufruf des VCR4OWB-Adapters bei markiertem Mapping über das Kontextmenü.
- Jetzt erkennt der Adapter, dass das Mapping geändert ist (blaues Zahnrad).
Über die Schaltfläche Commit wird der Vorgang für das geänderte Mapping in dem Versionsmanagement gestartet. Auch jetzt gilt: Es muss eine aussagekräftige Beschreibung der Änderung vorgenommen werden.
-
Das Mapping ist jetzt aktuell von Benutzer A im SVN-Repository eingecheckt. D.h., dass das Mapping in der Sandbox des Benutzers A identisch ist mit dem Mapping im Versionsmanagement.
2. Der Benutzer B führt weitere Änderungen an dem Mapping durch, indem er den Ladetyp der Zieltabelle von INSERT auf TRUNCATE/INSERT stellen möchte.
-
Benutzer B hat aktuell einen anderen Versionsstand in seiner Entwicklungsumgebung.
Der Benutzer B muss über den VCR4OWB-Adapter prüfen, ob es eine Weiterentwicklung an diesem Mapping gegeben hat. Tut er das nicht, kommt es spätestens beim nächsten Commit zu einem Konflikt – aber dazu später mehr. Bei Aufruf des Adapters wird das SVN-Repository mit der eigenen Sandbox verglichen und der Adapter erkennt, dass ein anderer Benutzer das Mapping geändert hat.
Über die Schaltfläche Update wird die Sandbox des Benutzers B mit dem aktuellen Mapping aus dem Versionsmanagement aktualisiert. Der Benutzer kann jetzt die gewünschte Änderung (Loading Type) durchführen und das Mapping wieder in das Versionsmanagement einchecken.
