In den letzten Jahren wurde CI/CD durch agile Methoden wie Scrum immer wichtiger in der Oracle Entwicklung. Ich arbeite momentan in einem agilen Oracle Apex Projekt, in dem ich, als Oracle Backend Developer, auch die Jenkins Auslieferungen betreue. Ich möchte hier einige Entscheidungen und Methoden beschreiben, die CI bei agilen Vorgehensweisen vereinfachen können.
Hauptziele für effizientes CI/CD
Das Ziel einer jedem CI/CD Kette in Oracle Datenbanken besteht darin, dass alle Batches fehlerfrei verlaufen. Das heißt, dass man fachliche Testumgebungen erstellt, die
- Testdaten so wenig wie möglich zerstören
- keine GUI zerstören
„Super CI Schema“ oder „alles Lokal“
Zur Erreichung dieser Ziele muss zunächst entschieden werden, wie Datenbankänderungen durchgeführt werden. Es ist sinnvoll, ein beliebiges Schema als CI Schema anzuweisen, in dem man alle CI spezifischen Tools erstellt. Dann kann man entweder diesem Schema volle DBA Rechte geben und alle Datenbankänderungen aus diesem CI Schema heraus durchführen (Super CI) oder man kann allen anderen Schemata die notwendigen Rechte geben, um die Tools bei Installationen zu benutzen (Alles lokal).
- Super CI
Bei Super CI ist alles zentral. Ein Nachteil ist jedoch, dass bei allen Aktionen das Zielschema spezifiziert werden muss.
- Alles lokal
Hier ist es unnötig, das Zielschema zu spezifizieren, dafür braucht jedes Schema einen eigenen Job.
Beide Alternativen haben also ihre Vor- und Nachteile. Man kann sowohl „Super CI“ als auch „Alles Lokal“ nutzen, jedoch sollte man die jeweilige Methode stets sauber anwenden. Es gibt auch Mischformen, bei diesen werden jedoch die Vor- sondern auch die Nachteile kombiniert, weshalb von der Nutzung der Mischformen abzuraten ist.
Abhängigkeiten von Objekten in der Datenbank
Die wichtigste Fehlerquelle bei Installationen in Oracle Datenbanken sind Abhängigkeiten. Um daraus resultierende Fehler zu vermeiden, kann man verschiedene Hilfsmittel nutzen: Oracle Data Dictionary, z.B. View ALL_OBJECTS.
Diese haben folgende Hauptziele:
- Nie etwas erstellen, das es schon gibt.
- Nie etwas ändern oder entfernen, das es nicht mehr gibt.
- Nie etwas erstellen, das abhängig von etwas ist, das es noch nicht gibt.
- Nie etwas entfernen, wovon noch bestehende Objekte abhängig sind.
Wichtige Faustregeln zur Vermeidung von Fehlern
Erste Faustregel:
Zur Vermeidung einer Fehlerquelle sollte ein „Single Point of Truth“ angestrebt werden . Das heißt, dass, wenn man ein bestimmtes Objekt bearbeiten möchte, aus der Kombination von Änderung, Schema und Objekttyp automatisch hervorgeht, welche Datei in welchem Verzeichnis dafür erstellt oder bearbeitet werden muss. Alle notwendigen Aktionen werden also in diese Datei umgesetzt. Es werden alle Reihenfolge-Abhängigkeiten von Installationsskripts abgesichert.
Leider ist das nur für Mini-Anwendungen und „Big Bang“ Installationen realistisch umsetzbar. Bei agilen Arbeitsweisen, bei denen das Datenmodell mehrere Male geändert wird, müssen andere Hilfsmittel hinzukommen.
Zweite Faustregel:
Entferne nie etwas, wenn es nicht stört. Grundvorgehen bei der agilen Entwicklung in Oracle ist, dass nur erweitert wird. Erst ganz am Ende des Prozesses werden Altlasten entfernt. Diese Regel ist wichtig, denn es geht darum, über so viele intakte Testdaten wie möglich zu verfügen, damit Änderungen so schnell wie möglich für den Kunden sichtbar gemacht werden können. Wenn „veraltete“ Komponenten beibehalten werden, braucht man nicht gleich alle möglichen Use Cases und Abhängigkeiten zu durchdenken. Die alten Daten existieren noch, falls sie später an anderen Stellen gebraucht werden.
Beispiel: Entferne Stammdaten Records indem ein Filter auf eine zwischengeschaltete View gesetzt wird, statt Records zu entfernen. Entferne Spalten, indem sie versteckt werden („Hidden“).
Dritte Faustregel:
Der Kunde liefert die Testfälle. Es ist allerdings die Verantwortlichkeit des Entwicklerteams, diese Testfälle so häufig wie möglich zu benutzen. Dazu ist es notwendig, Vorgehensweisen zu definieren, um diese Testfälle immer wieder in die Entwicklungsumgebung übernehmen zu können.
Am besten werden Tools erstellt, die das Ziel haben,:
- alle notwendigen Records für einen Testfall auf einmal zu kopieren.
- die Ausgangssituation immer wieder herstellen zu können.
- die Tests nach jeder Auslieferung automatisch durchführen zu können.
- bei Datenbankfehlern alle relevanten Records automatisch als Testfall zu speichern.
Vorteile durch Record Parameter
Weil sich bei agilen Methoden das Datenmodell oft ändert, ist nicht zu übersehen, welche Parameter sich bei weiteren Entwicklung ändern werden. Wenn man so viele Record Typen wie möglich benutzt, kann eine einzelne Record Änderung mehrere sonst notwendigen Parameteränderungen ersetzen. Ein zweiter Vorteil ist, dass weniger Datenbankobjekte invalid werden, also Entwicklertests leichter durchzuführen sind.
Auch die GUI Schnittstellen können hiermit stabiler gemacht werden. Wenn ein Funktionsanruf einen Rekordtyp füllt und daraus die GUI Felder gefüllt werden, bleiben Masken, die diese Funktion benutzen, valide solange die verwendeten Felder anwesend bleiben. Beim direkten Befüllen werden auch alle Masken invalid, selbst wenn sie die Änderung inhaltlich ignorieren könnten.
Werden all diese Hilfsmittel beachtet, steht einer erfolgreichen agilen Entwicklung mit Oracle Datenbanken nichts mehr im Wege.