Agile Oracle database modeling and development - APEX Connect 2020

Agile Oracle Datenbank-Modellierung und -EntwicklungAgile Oracle Datenbank-Modellierung und -Entwicklung
@develishdevelop #APEXCONN20 #AgileOracleDatabase
Agile Oracle Datenbank-
Modellierung und -Entwicklung
6.5.2020 - Torsten Kleiber



1

Agenda
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
Agenda
Einführung
Über meinen Arbeitgeber
Über mich
Was ist Test Driven Development (TDD)?
Wie sieht meine Datenbank-Entwicklungsumgebung aus?
utPLSQL - Tes ramework für Oracle Datenbank
TDD in der Datenbank-Entwicklung
Datenbank Design mit Liquibase
So ware Development Lifecycle (SDLC)
TDD in der Datenbank-Modellierung
TDD in der Qualitätssicherung
Umgang mit Merge Konﬂikten
Fazit
Q&A



2

Einführung
Was meinen wir eigentlich, wenn wir sagen wir wollen agil sein?
Anforderungen sind nicht fest und können sich während der Realisierung ändern!
Parallelisierbarkeit der Umsetzung
Dann machen wir doch Features in Branches!
Wie merged man die, wenn diese einsatzbereit sind?
Wie erkenne ich, was von was abhängig ist?
Automa sche Tests zeigen, ob nach dem Merge noch alles funk oniert!
Und wie bekomme ich genügend automa sche Tests?
Test Driven Development wird das schon richten!
Ja - in der Frontend-/Java-/XXX-Entwicklung geht das vielleicht!
Was ist aber die wirkliche Grundlage der meisten unserer Anwendungen?
Die Oracle Datenbank mit Datenmodell und Programmiersprache PL/SQL!
Da geht das alles aber doch gar nicht!
Warum eigentlich nicht?
Wie geht das: agil und testgestrieben von der Anforderung bis zum Refactoring?
Begeben wir uns auf unsere Reise!


3

Über meinen Arbeitgeber



4

Über mich
Torsten Kleiber
So ware-Architekt, Entwickler, DevOps,
Administrator
Kreditpla orm
Seit 20 Jahren bei der IKB
23 Jahre Erfahrung
PL/SQL
Forms & Reports
ADF
SOA Mediator
Architektur & Infrastruktur
Fusion Middleware
Development Tools
Development Lifecycle



5

““
Was ist Test Driven Development (TDD)?
Test-driven development (TDD) is a so ware development
process that relies on the repe on of a very short development
cycle:
Requirements are turned into very speciﬁc test cases, then the
so ware is improved so that the tests pass.
This is opposed to so ware development that allows so ware to
be added that is not proven to meet requirements.
— Wikipedia



6.1

TDD: einfacher Zyklus



6.2

TDD: globaler Zyklus



6.3

TDD: Voraussetzungen
vollständige Entwicklungsumgebung pro Entwickler inclusive Datenbank
am besten lokal
generische Build-, Deployment- und Test-Prozesse für Entwicklung und CI
Open Mind: Entwickler muss die Methode akzep eren und leben!



6.4

Wie sieht meine Datenbank-
Entwicklungsumgebung aus?
Neben IDE’s ist in unserem Fall die Datenbank bereitzustellen.
Folgende Op onen bieten sich an:
seperate Schemas für jeden User in einer Datenbank
nur bei 1 Applika onsschema
aufwändige Applika ons-Konﬁgura on
Grant-/Synonym-Hölle zwischen Daten- und Applika onsschemas
Virtuelle Maschinen oder Docker Container
rela v hohe Laufzeiten bei wiederholter Erstellung
Snapshot Copies
EE mit Mul tenant Op on erforderlich (> 2 Snapshot Copies)
schnelle Erstellung
…



7.1

Datenbank: Vorbereitung
1. Download (Pre-Built Developer VMs for Oracle
VM VirtualBox)
2. VM impor eren und starten per GUI oder CLI:
VBoxManage import %download_path%DeveloperDaysVM2019-05-31_20.ova ^
--vsys 0 --cpus 4 --memory 16384 --eula accept
VBoxManage startvm "Oracle DB Developer VM"
3. Gasterweiterungen manuell einlegen und ausführen, danach Savepoint erstellen
VBoxManage snapshot "Oracle DB Developer VM" take base --live
4. utPLSQL in PDB installieren
curl -Lk gitreleases.dev/gh/utPLSQL/utPLSQL/latest/utPLSQL.zip -o utPLSQL.zip
tar -xf utPLSQL.zip
pushd utPLSQLsource
sqlplus sys/oracle@//localhost/orcl as sysdba @install_headless.sql
5. Snap Shot Copy konﬁgurieren
connect sys/oracle@//localhost/orclcdb as sysdba
-- Ändern des Parameters clonedb der CDB
alter system set clonedb=true scope=spfile;
shutdown immediate
startup
-- PDB orcl nur für Lesen öffnen, da hier nur als Template genutzt
alter pluggable database orcl open read only force;
Database App Development VM



7.2

Datenbank: Snapshot Copy erzeugen / löschen
1. Pro User oder Branch wird eine neue Snapshot Copy erzeugt und je nach
Anforderung der zu nutzende Servicename übergeben.
2. Das Löschen erfolgt ebenfalls über den Servicenamen.
-- Anmelden an die CDB
alter pluggable database &1 close;
drop pluggable database &1 including datafiles;
-- Anmelden an die CDB
-- PDB orcl nur für Lesen öffnen, da hier nur als Template genutzt
alter pluggable database orcl open read only force;
create pluggable database &1 from orcl create_file_dest = '/u01/app/oracle/oradata/ORCLCDB' snapshot copy
alter pluggable database &1 open;



7.3

utPLSQL - Testframework für Oracle Datenbank
ursprünglich von Steven Feuerstein entwickelt
2016 komple neu geschrieben und jetzt wirklich reif für den
professionellen Test
100% Opensource und kostenlos
unterstützt den TDD Zyklus
einfach
utPLSQL Name unglücklich gewählt, da nicht nur für Unit-Tests nutzbar
selbst in PL/SQL geschrieben
Tests sind selbst Packages
alles testbar, was ich in der Datenbank machen kann
orien ert sich an anderen Frameworks wie jUnit etc.
zum Vergleich erwarteter und aktueller Ergebnisse
arbeitet mit (Vorsicht mit Forma ern!)
über PL/SQL (ut.run), CLI, SQL Developer / TOAD Plugin
verschiedene für Screen, XUnit, Teamcity, Sonar und
bringt mit
installierbar
Expecta ons und Matcher
Annota onen
Ausführung
Reporter Code Coverage
Best Prac ces


8

TDD in der Datenbank-Entwicklung
Wir wollen eine einfache Annuität berechnen:
Demo me → 



9.1

Neues Test Package
1. Erzeuge einen neuen Branch und pushe ihn
2. Schreibe einen neuen Test!
CREATE OR REPLACE PACKAGE test_annuitaeten AS
--%suite(Annuitaetenberechnung)
--%test(Normale Nutzung)
--%tags(unit)
PROCEDURE normale_nutzung;
END;
/
3. Prüfe, dass der Test scheitert!



9.2

Neuer Test Package Body
1. Schreibe die Tes mplemen erung!
CREATE OR REPLACE PACKAGE BODY test_annuitaeten AS
PROCEDURE normale_nutzung IS
BEGIN
ut.expect(annuitaeten.get_annuitaet(250000, 0.05, 10)).to_equal(32376.143741364173874951668563451
END;
END;
/



9.3

Code
1. Schreibe genau so viel Code, das der Test erfolgreich ist!
2. Prüfe, dass der Test erfolgreich ist!
CREATE OR REPLACE PACKAGE annuitaeten AS
FUNCTION get_annuitaet (
kreditsumme IN NUMBER,
zinssatz IN NUMBER,
laufzeit IN NUMBER
) RETURN NUMBER;
END;
/
CREATE OR REPLACE PACKAGE BODY annuitaeten AS
FUNCTION get_annuitaet (
kreditsumme IN NUMBER,
zinssatz IN NUMBER,
laufzeit IN NUMBER
) RETURN NUMBER IS
BEGIN
RETURN kreditsumme * (((1 + zinssatz) ** laufzeit) * zinssatz) / (((1 + zinssatz) ** laufzeit) -
END;
END;
/



9.4

““
Datenbank Design mit Liquibase
One of the biggest ques ons is how to make evolu onary design
work for databases.
— Pramod Sadalage (Thoughtworks)



10.1

Liquibase: Einführung
migra ons-basiertes Datenbank-Change-Management
, u.a. Oracle, MySQL, SQL Server,
Sybase, DB2, SQLite …
: CLI, ANT, Maven, Spring …
Textbasiertes Change Log File steuert die Ausführungs-Reihenfolge
atomare Change Sets inline oder als Include
: Eine Änderung pro Change Set
Change Set Formate:
deklara v: XML, YAML, JSON (generiert aus den Changes SQL für Ziel-
Datenbank, teilweise inclusive Rollback)
(Datenbank-speziﬁsche Dialekte möglich)
/ der Datenbank mit incl. Hash
Steuerung von Changesets durch vordeﬁnierte (Datenbank, SQL
Abfrageergebnis, …)
Steuerung durch dem Runner mitgegebene (Testdaten nur auf Test, …)
dem Runner mitgegebene können im Changeset als Variable genutzt
werden (Tabelle, Spalte, …)
datenbankunabhängig
Runner
Best Prac ce
SQL
Update Rollback Tracking in Datenbanktabellen
Pre-Condi ons
Contexts
Parameter



10.2

Liquibase CE: Community Edition
kostenlose Variante von Liquibase
Viele Oracle Objekte werden durch die nicht unterstützt, z.B.
PL/SQL
Change Log Format SQL unterstützt komple en Sprachumfang von Datenbanken
Rollback muss dann, wenn erforderlich, auch selbst in SQL geschrieben werden
Reihenfolge der Ausführung wird selbst festgelegt
Change Tags



10.3

Liquibase CE mit Community Oracle Extensions
unterstützen weitere Objekte, u.a.
Check-Constraints
Trigger
Materialized Views
Disable/Enable Check-Constraints/Trigger
Merge
Truncate
kein PL/SQL
seit mehreren Jahren nicht mehr gepﬂegt
Oracle Change Tags werden als Pro Tag erkannt und ohne Lizenz verweigert:
<changeSet author="torst (generated)" id="1573059733408-39">
<ora:createTrigger
...
Change Type 'pro:createTrigger' is not allowed without a valid Liquibase Pro License.
Einsatz m.E. deshalb nicht zu empfehlen
Oracle Extensions



10.4

Liquibase Professional Edition
kostenpﬂich ge Liquibase Version von Da cal
der Liquibase PRO-Version unterstützen weitere Objekte, u.a.
Check-Constraints
PL/SQL (Func on/Procedure, Package, Package Body)
Synonyme
Trigger
Unused Columns
keine Materialized Views
kein Rollback
Preis abhängig von
14 tägige verfügbar
Einsatz nicht getestet
Change Tags
Anzahl Datenbankverbindungen
Trial



10.5

>_
Liquibase CE mit Oracle’s Oracle Extensions
Capture von Objekten nur per SQLcl ab Version 19.2
dafür zusätzliche Tabelle DATABASECHANGELOG_EXPORT
als XML Changeset
über DBMS_METADATA
incl. Rollback
derzeit nur für angemeldeten Benutzer
Reihenfolge wird automa sch erzeugt
DDL Preview Modus
Deployment von Objekten
per SQLcl ab Version 19.2.1
per Liquibase-API’s mit oracle-liquibase.jar in in liquibase/lib/ext
unterstützt Oracle Datenbank 11.2+
supportete Objek ypen
Dokumenta on



10.6

Welche Variante nimmt man nun?
Analyse über ein Legacy-System, hier
das Demo-Schema HR



10.7

““
““
““
““
““
““
““
Liquibase ORA: Fazit
Oracle’s Liquibase Extensions zeichnet Oracle-Datenmodelle und
-Programme auf und kann diese auch wieder einspielen.
Daten werden nicht aufgezeichnet und eingespielt.
Diﬀ nach Änderung wird nicht erzeugt.
Eigenes Change Set Format, Schema nicht dokumen ert.
Nutzung nur mit gebündelter Liquibase Version möglich.
Die Extension hat prinzipiell Potenzial.
→ erste Version, später wieder anschauen!


10.8

““
““
““
Liquibase CE: Generieren des Legacy Change
Logs
Generierung leidet unter mangelnden Support von Oracle
Objekten.
Nacharbeiten wiegen Generierung der Objekte nicht auf.
Wenn ich sowieso SQL Changesets nutzen will, weil ich nur dort
alle Oracle Objekte nutzen kann, gibt es vielleicht einen anderen
Weg der Generierung außerhalb von Liquibase?



10.9

SQL Developer: Legacy Database Change Log (1)
1. Tools → Database Export



10.10

SQL Developer: Legacy Database Change Log (2)
2. Master SQL File wird mitgeneriert
3. Mit Tastaturmakros ist daraus leicht das Database Change Log zu erzeugen
Bei Triggern und PL/SQL muss der endDelimiter korrekt auf
"n/s*n>|n/s*/$" gesetzt werden! (n = Zeilenumbruch, s* =
beliebig viele Whitespace-Zeichen, $ = Dateiende, | = oder)
--------------------------------------------------------
-- File created - Thursday-November-07-2019
--------------------------------------------------------
@X:gitde.kleiber.demos.oracle.database.tddsrcmainresourcesliquibaselb_sqldSEQUENCESDEPARTMENTS_S
...
@X:gitde.kleiber.demos.oracle.database.tddsrcmainresourcesliquibaselb_sqldPROCEDURESADD_JOB_HIST
...
<databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog" xmlns:appdba="http://www.datical.n
<changeSet id="0000000000000-1" author="legacy">
<sqlFile path="SEQUENCES/DEPARTMENTS_SEQ.sql" relativeToChangelogFile="true"/>
</changeSet>
...
<changeSet id="0000000000000-41" author="legacy">
<sqlFile path="PROCEDURES/ADD_JOB_HISTORY.sql" relativeToChangelogFile="true" endDelimiter="n/s
</changeSet>
...




10.11

Liquibase: Sync Legacy System mit Changelog
Anforderungen:
Datenmodell und Daten sollen nicht geändert werden
Liquibase Tabellen sollen angelegt werden
Change Sets sollen als ausgeführt eingetragen werden
→ Alles in einem Befehl:
liquibase --driver=oracle.jdbc.OracleDriver ^
--classpath="%oracle_home%ojdbc8.jar" ^
--changeLogFile=%~dp0lb_sqldcontroller.xml ^
--url="jdbc:oracle:thin:@localhost/%1" ^
--username=hr ^
--password=oracle ^
changelogSync



10.12

““
““
““
““
Liquibase CE: Fazit
Liquibase CE ist für Oracle nutzbar,
wenn speziﬁsche Oracle Objekte wie z.B. Check Constraints
oder PL/SQL nicht genutzt werden müssen
oder für diese SQL Change Sets inklusive SQL Rollback
Statements erzeugt werden.
Forma ed SQL Changelogs sollten nicht genutzt werden, diese
sind stark bugbeha et.
Sta dessen sollte der genutzt werden.
Sowohl Legacy als auch Updates generell lassen sich per SQL
Developer Database Export erzeugen.
Change sqlFile



10.13

Software Development Lifecycle (SDLC)
Empfehlung:
Toolchain, die Branches und Pull Requests (incl. Merge) automa sch baut
hier: Jenkins Mul branch Pipeline mit Github- oder Bitbucket-Repository



11.1

Ablauf
1. Anforderung sollte möglichst klein
aber unabhängig sein
2. Branch wird nach jedem Push in
Branch gebaut
3. Pull Request wird nach jedem Push
in Branch oder Master gebaut
4. Beim Bauen wird der Master auf
den Pull Request testweise
gemerged



11.2

TDD in der Datenbank-Modellierung
Die Daten weisen auf den ISO 3166-1 ALPHA-2 Code hin, aber da fehlen doch
Validierungen?
Demo me → 


12.1

Neuer Branch



12.2

Neues Test Package
CREATE OR REPLACE PACKAGE test_iso3166 AS
--%suite(ISO 3166 Laendercodes)
--%test(ALPHA-2 Code muss uppercase sein)
--%throws(-02290)
--%tags(model)
PROCEDURE alpha2_uppercase;
END;
/



12.3

Neuer Test Package Body
1. Schreibe die Tes mplemen erung!
CREATE OR REPLACE PACKAGE BODY test_iso3166 AS
PROCEDURE alpha2_uppercase IS
BEGIN
INSERT INTO countries (country_id, country_name, region_id)
VALUES ('xx', 'name', 1);
END;
END;
/



12.4

Code
ALTER TABLE "HR"."COUNTRIES"
ADD CONSTRAINT "COUNTRY_ID_UPPERCASE" CHECK ( country_id = upper(country_id) ) ENABLE;



12.5

Weiterer Test
1. Schreibe einen weiteren Test und die Implemen erung!
...
--%test(ALPHA-2 Code muss zweistellig sein)
--%throws(-02290)
--%tags(model)
PROCEDURE alpha2_zweistellig;
...
PROCEDURE alpha2_zweistellig IS
BEGIN
INSERT INTO countries (country_id, country_name, region_id)
VALUES ('X', 'name', 1);
END;
...



12.6

Code
ADD CONSTRAINT "COUNTRY_ID_ISO_3166_ALPHA2" CHECK (REGEXP_LIKE(COUNTRY_ID, '^[[:alpha:]]{2}$')) ENABL



12.7

Refactor
1. Verbessere den Code, ohne sein Verhalten zu ändern!
ALTER TABLE "HR"."COUNTRIES" DROP CONSTRAINT "COUNTRY_ID_ISO_3166_ALPHA2";
ADD CONSTRAINT "COUNTRY_ID_ISO_3166_ALPHA2" CHECK (REGEXP_LIKE(COUNTRY_ID, '^[[:alpha:]]{2}$') AND CO
ALTER TABLE "HR"."COUNTRIES" DROP CONSTRAINT "COUNTRY_ID_UPPERCASE";



12.8

Skripte erstellen, testen und versionieren (1)
1. Skripte wie gehabt aus SQL Developer erstellen
2. Testen
a. Apply Changelog auf lokalen Entwicklungs-Snapshot
b. Test mit SQL Developer
c. Prüfen, ob alle neuen Tests erfolgreich sind



12.9

Skripte erstellen, testen und versionieren (2)
3. Commit



12.10

Branch pushen



12.11

CI: Branch wird gebaut und getestet



12.12

Pull Request nach 1. Branch Commit erstellen



12.13

CI: Pull Request wird nach jedem Push gebaut



12.14

TDD in der Qualitätssicherung
Braucht jede Tabelle einen Primary Key?



13.1

Neues Test Package
CREATE OR REPLACE PACKAGE test_qa AS
--%suite(Qualitaetsanalyse)
--%test(Jede Tabelle muss einen Primary Key haben)
--%tags(qa)
PROCEDURE table_pk;
END;
/



13.2

Code
CREATE OR REPLACE PACKAGE BODY test_qa AS
PROCEDURE table_pk IS
l_expected SYS_REFCURSOR;
l_actual SYS_REFCURSOR;
BEGIN
OPEN l_expected FOR SELECT * FROM user_tables t WHERE 0=1;
OPEN l_actual FOR SELECT * FROM user_tables t WHERE NOT EXISTS (
SELECT * FROM user_constraints c WHERE c.table_name = t.table_name AND c.constraint_type = 'P'
);
ut.expect(l_actual).to_equal(l_expected);
END;
END;
/



13.3

Code
BEGIN
OPEN l_expected FOR SELECT * FROM user_tables t WHERE 0=1;
OPEN l_actual FOR SELECT * FROM user_tables t WHERE NOT EXISTS (
SELECT * FROM user_constraints c WHERE c.table_name = t.table_name AND c.constraint_type = 'P'
) AND t.table_name != 'DATABASECHANGELOG';
END;
END;
/



13.4

Refactor
1. Verbessere den Code, ohne sein Verhalten zu ändern!
BEGIN
OPEN l_expected FOR SELECT t.table_name FROM user_tables t WHERE 0=1;
OPEN l_actual FOR SELECT t.table_name FROM user_tables t WHERE NOT EXISTS (
SELECT 1 FROM user_constraints c WHERE c.table_name = t.table_name AND c.constraint_type = 'P'
) AND t.table_name != 'DATABASECHANGELOG';
END;
END;
/



13.5

weitere SDLC Schritte
1. Skripte erstellen, testen und versionieren
2. Branch pushen
3. CI: Branch wird gebaut und getestet
4. Pull Request nach 1. Branch Commit erstellen
5. CI: Pull Request wird nach jedem Push gebaut



13.6

Merge Pull Request



13.7

Branch löschen



13.8

Umgang mit Merge Konflikten



14.1

Merge Konflikt im Pull Request für Branch
model



14.2

Merge Konflikt lösen



14.3

Commit Merge



14.4

CI: Branch wird gebaut und getestet



14.5

CI: Pull Request wird nach jedem Push gebaut



14.6

weitere SDLC Schritte
1. Merge Pull Request
2. Branch löschen



14.7

Master Build erfolgreich incl. aller Tests/
Änderungen



14.8

Fazit
Yes - we can agile Datenbank-Entwicklung und Modellierung!
Branchen und Mergen sind möglich!
Paralleles Entwickeln/Testen unter Berücksich gung von Abhängkeiten möglich!
Toolchain mit Liquibase, utPLSQL, GitHub/Bitbucket, Jenkins unterstützt uns



15

Q&A



16

Referenzen
, Xaver Pigeon
, Johannes Ahrends, CarajanDB
, Wikipedia
, Pramod Sadalage, Thoughtworks
, Jeﬀ Smith, Oracle
, Dokumenta on, Oracle
, AskTom, Oracle
Test-Driven Development: global cycle
Mul tenant Snapshot Copy
Annuitätendarlehen
Evolu onary Database Design
Liquibase and SQLcl
Using Liquibase with SQLcl
Primary Key



17

Agile Oracle database modeling and development - APEX Connect 2020

Weitere ähnliche Inhalte

Was ist angesagt?

Agile Oracle database modeling and development - APEX Connect 2020