Bob the Builder - Build & Deploy von ADF Enterprise Anwendungen

Bob the Builder: Build/Deploy von
ADF Enterprise Anwendungen
Torsten Kleiber, IKB Deutsche Industriebank AG
DOAG, 17.11.2015

IKB – Bank des Mittelstands
IKB im Überblick
Leistungsspektrum
Regionale Präsenz
2
 Seit über 90 Jahren Finanzierungspartner des
Mittelstands
 ca. 1.100 Kundengruppen in Deutschland und
Europa und ca. 20.000 Kundengruppen im
Leasing-Geschäft
 Aktionäre: Lone Star 91,5 %,
Streubesitz 8,5 %
 ca. 1.500 Mitarbeiter
 Bilanzsumme: 22 Mrd. €
 Common Equity Tier 1-Quote1): 10,90 %
Mailand
London
Paris
Madrid
München
Stuttgart
Frankfurt
Düsseldorf (HQ)
Berlin
Hamburg
Fördermittel
Konsortial-
finanzierung
Leasing
Equity
Capital Markets
Advisory
M&A
Corporate Finance
Restrukturierung
Debt AdvisoryDerivate
Sales & Trading
Kredit
Bilaterale
Finanzierung
Capital Markets
Debt
Capital Markets
Anmerkung: Kennzahlen per 31. März 2015
1) Alle Angaben nach Bilanzfeststellung und unter stichtagsgleicher Zurechnung der Dotierung des Fonds für allgemeine Bankrisiken im CET 1 sowie unter Berücksichtigung der Ein- und Ausphasungsregelungen der CRR des
Jahres 2015 bzw. des Vorjahres. Die CET 1-Quoten wurden nach aktuellem Rechtsstand der CRR zum 31. März 2015 bzw. des Vorjahres inklusive Übergangsvorschriften sowie der bekannten Interpretationen der Aufsicht und
deren Auslegung ermittelt. Es ist nicht auszuschließen, dass zukünftige EBA-/EZB-Standards/Interpretationen bzw. sonstige aufsichtliche Handlungen retrograd zu einer abweichenden CET 1-Quote führen können.

Über mich
Torsten Kleiber
Software Architekt, Entwickler
Kreditplattform
16 Jahre IKB, 19 Jahre Oracle Erfahrung
von
Designer / Forms / Reports
PL/SQL
zu
Architektur & Infrastruktur
Fusion Middleware
SOA Mediator
ADF
Development Tools
Development Lifecycle
Release Management
3

Rahmenbedingungen
Seit 4 Jahren ADF Entwicklung
Start: einfache Anwendungen und wenige Entwicklern
Neuentwicklung für das Kreditgeschäft
Ablösung Eigenentwicklung für das Kreditgeschäft
-~ 500 Forms, 60 Menüs, 40 Bibliotheken, 350 Reports
-50% in englisch
Integration der vorhandenen ADF Anwendungen
bis 15 parallele Entwickler an komplexen Anwendungen
JDeveloper/ADF 11.1, Prio 1 Bug für 12c nicht gefixt
Umstellung auf advanced Pillar-Architektur vollzogen
1) http://de.slideshare.net/tkleiber/das-dreckige-dutzend-adf-migration-nach-12c-in-der-ikb-doag-2014-prsentation
2) http://de.slideshare.net/chriscmuir/150-v10-design-adf-architectural-patterns
4

Bob‘s Geburt
Start ADF Entwicklung mit Lernprojekt
Kein Know-How für Build/Deployment vorhanden
Build/Deployment war/ist Blackbox für viele Entwickler
Kann man das automatisieren?
Können wir das schaffen?
Alle sagen:
-Wir brauchen jemanden der das macht!
-Bob?
5

Unsere Sourcen sollen magisch geöffnet, gebaut und
paketiert werden!
Können wir das schaffen?
Bob der Baumeister sagt: Yo, wir schaffen das!
Wir brauchen Build-Tools!
6

Kennen Sie OJ-Tools?
Subset von JDeveloper Funktionen - Headless
bei Aufruf wird dieses gestartet und gestoppt
Windows:
dir %JDEV_HOME%jdeveloperjdevbinoj*.exe
Unix/Linux:
ls $JDEV_HOME/jdeveloper/jdev/bin/oj*
Tools für Audit, Formatierung, Indizierung, SCA Compiler,
Migration, Extensions, Build & Packaging
oj*64* Tools: mit 64bit JDK automatisch aufgerufen
12c: oj*.conf? Nicht dokumentiert!
7

Build-Tools: ojdeploy - Überblick
kein Deploy, sondern Build und Packaging
Andere nicht supported (deklarative Komponenten etc.)
Hilfe genau lesen (11g: ojdeploy, 12c: ojdeploy –help)
-workspace: Pfad zur .jws-Datei (evt. relativ zu –basedir)
-project: wie im Workspace benannt
-buildfile: aus Output der Kommandozeile übernehmen
11g auf Windows: ojdeploy nur mit 64bit JDK nutzbar, das
ist aber eigentlich nicht supported
Mindestens ein Deployment-Profil erforderlich
1) https://docs.oracle.com/middleware/1213/jdev/user-guide/jdev-build-java-projects.htm#OJDUG5835
2) https://docs.oracle.com/middleware/1213/jdev/user-guide/jdev-deploy-applications.htm#OJDUG643
8

Build-Tools: ojmake
Kein Deployment-Profil erforderlich
nur Build, keine Paketierung
Einsatzszenarien
Testprojekte im Workspace (Unit, GUI, Last etc.)
Build vor Paketierung z.B. in Build-Pipelines
Ganzen Workspace mit ojmake bauen
Deployment-Profil mit ojdeploy paketieren (Compile-Zeit
entfällt, da bereits in ojmake erfolgt)
9

Build-Tools: Was wird gebaut?
• “Make operations compile source files that have changed
since they were last compiled, or have dependencies
that have changed.”
• was heißt das?
10

Build-Tools: Was wird gebaut? - Ausgangslage
Ausgangslage
Zwei Projekte im selben Workspace
Alle Klassen im selben Paket
Klasse abhängig von Klassen-
Methode trunc im Source-Projekt
Klasse im Testprojekt abhängig von
Klassen-Methode trunc im Source-
Projekt
Methode trunc wird geändert, ein Pa-
rameter hinzugefügt oder umbenannt
Werden die abhängigen Klassen
automatisch gebaut?
11

Build-Tools: Was wird gebaut? - Dependencies
Arten
-Build Output
-Deployment Profile
-Libraries (inkl. ADF Libraries)
Bei ADF Libraries nicht zusätzlich
den Build Output verknüpfen 
doppelte Klassen im Classpath!
Refactoring nutzen! Fkt. aber
-nur im selben Workspace
-nur bei Build Output Dependen-
cies auch in anderen Projekten
im selben Workspace
12

Build-Tools: Was wird gebaut? - Analyse
Änderung trunc 13:12, Bauen Workspace 13:18
ojmake %cd%ikb.adf.basis.jws
Ergebnis
30.10.2015 13:12 JavaHelper.java
30.10.2015 11:57 JavaConsumer.java
29.10.2015 22:06 JavaHelperTest.java
30.10.2015 13:18 JavaHelper.class
30.10.2015 13:18 JavaConsumer.class
30.10.2015 13:07 JavaHelperTest.class
kein Build-Fehler im abhängigem Projekt
Laufzeitfehler sind evtl. zu erwarten!
13

Build-Tools: Was wird gebaut? - Ergebnis
gebaut wird, was angefordert ist: Projekt oder Workspace
Klasse in abhängigem Projekt wird nur gebaut, wenn
-deren Source geändert wird (nur bei Refactoring + Build
Output)
-Abhängigkeiten selbst geändert werden
-Schalter -clean verwendet wird (Deploy und Build Output
wird vor Build gelöscht), Build dauert dann aber länger
-clean per VCS „remove unversioned files“ evtl. schneller
-Klasse in abhängigem Workspace wird nie gebaut
Fazit: Baue clean! (spätestens vor dem Checkin/Deploy)
14

Build-Tools: ojdeploy – Laufzeiten (1)
Aufruf 1x pro Deployment-Profil
ojdeploy -workspace path1ws1.jws -project pj1 -profile
pf -clean
…
ojdeploy -workspace pathXwsX.jws -project pjX -profile
pf -clean
…
ojdeploy -workspace path1ws1.jws -profile pf
…
ojdeploy -workspace pathXwsX.jws -profile pf
n * Overhead für Start / Stopp ojdeploy
15

1 Aufruf mit buildfile
ojdeploy -buildfile
pathbuildfile.xml
1x Overhead für Start/Stopp
ojdeploy
Nur marginale Unterschiede
in Gesamtlaufzeit zwischen
-normaler und
-kompakter Beschreibung
16
<?xml version = '1.0' standalone = 'yes'?>
<ojdeploy-build>
<defaults>
<parameter name="clean"/>
</defaults>
<deploy>
<parameter name="workspace" value="path1ws1.jws"/>
<parameter name="project" value="pj1"/>
<parameter name="profile" value="pf"/>
</deploy>
<deploy>
<parameter name="workspace" value="pathXwsX.jws"/>
<parameter name="project" value="pj1,...,pjX"/>
</deploy>
<deploy>
<parameter name="workspace" value="path1ws1.jws"/>
</deploy>
<deploy>
<parameter name="workspace"
value="path1ws2.jws,...,pathXwsX.jws"/>
</deploy>
</ojdeploy-build>

17
IKB aktuell
-65 ADF Libraries
-10 Pillar Applikationen
-1 Rahmen-Applikation
00:28:00
00:06:39
0:00 0:15 0:30 0:45
Aufruf mit buildfile
separate Aufrufe

Build-Tools: ojserver Überblick
Ab JDeveloper 12c separat startbar
ojserver -start -address localhost:2010
Verwendung in ojdeploy
ojdeploy -ojserver -address localhost:2010 …
Keine Verwendung in anderen OJ-Tools!
Build sequentiell - bei parallelen Anfragen Fehler
CI Server: 1 ojserver pro Umgebung mit separatem Port
18

Build-Tools: ojserver - Probleme
Teilweise (ohne ojserver) nicht reproduzierbare Fehler
Fehler nur in ojserver Prozess gelistet  oj*.conf?
19
ojserver restriktiver!
Fehler: Selbstreferenzierung
der Model ADF Library

Build-Tools: ojserver - Laufzeiten
Laufzeiten ojdeploy sind in 12c offensichtlich größer
Test-Umfang ähnlich ojdeploy
Achtung! Beispieldaten vom Client, nicht vom Buildserver!
20
01:11:30
00:18:14
00:12:34
00:13:28
0:00 0:15 0:30 0:45 1:00
und ojserver
separate Aufrufe
mit ojserver
separate Aufrufe
benötigt man Einzel-
aufrufe sollte Option
-ojserver benutzt werden
sonst ist Option -buildfile
die bessere Wahl

Unsere Artefakte müssen magisch auf Standalone-Server
verteilt werden?
Wir brauchen Deployment-Tools!
21

Deployment-Tools: weblogic.Deployer
Bestandteil der WebLogic Installation
Java basiert
WebLogic Server classes im CLASSPATH, z.B. per
setWLSEnv.sh/cmd
Aufruf
java weblogic.Deployer -adminurl
http://localhost:7001 -username weblogic -
password weblogic -deploy myapp.ear -id
myDeployment
1) http://docs.oracle.com/cd/E24329_01/web.1211/e24443/wldeployer.htm#DEPGD318
22

Die Build- und Deployment-Tools müssen immer wieder in
einer definierten Reihenfolge aufgerufen werden?
Wir brauchen
Build-Automatisierungs-Tools!
23

nicht integriert in JDeveloper 11g und 12c
Alle Tools sind aufrufbar
Shell-Scripting ist
-Stark abhängig vom Betriebssystem
-Schlecht testbar
-aufwändig
Bei IKB nur in begründeten Ausnahmefällen!
24
Buildautomatisierung: Shell-Scripting

Buildautomatisierung: WLST
WebLogic Scripting Tool
nicht integriert in JDeveloper 11g und 12c, aber in Oracle
Enterprise Pack for Eclipse (OEPE)
Basiert auf Python, Bibliotheken wiederverwendbar
Oracle Erweiterungen für
-weblogic.Deployer
-MDS Konfiguration
-WebLogic Server Konfiguration
-…
-Aber kein Build und Packaging!
Bei IKB nur in begründeten Ausnahmefällen!
1) http://docs.oracle.com/cd/E14571_01/web.1111/e13813/quick_ref.htm#WLSTC112
25

Buildautomatisierung: Maven
Apache Maven erst ab 12c im JDeveloper integriert
Oracle Maven Repository Artefakte für ADF erst ab 12c
 Derzeit keine Option für die IKB. Auf Wiedervorlage
nach Migration.
26

Buildautomatisierung: ANT - Überblick
Apache ANT integriert in JDeveloper 11g und 12c
Buildskripte werden als XML-Struktur abgelegt
Neben hunderten Standard- auch Oracle-Plugins für
-ojdeploy
-weblogic.Deployer
-WLST
Kaum abhängig vom Betriebssystem
IKB Ansatz
-wenn neue(s) Anwendung / Projekt korrekt konfiguriert
-dann wird diese(s) vom vorhandenen ANT Build gebaut
-wir nutzen nicht vom JDeveloper generierten Skripte
27

Buildautomatisierung: ANT - Resilienz/Build
Wie findet man neue Anwendungen / Projekte?
Lösung: subant in build.xml
<target name="build>
<subant target="sub_build" genericantfile="sub_build.xml">
<dirset dir="../../." includes="${inc}" excludes="${exc}"/>
ojdeploy-Aufrufe in sub_build.xml:
<target name="sub_build">
<ora:ojdeploy xmlns:ora="oraclelib:OJDeployAntTask"
executable="${ojdeploy}" failonerror="true">

<arg value="-ojserver -address localhost:${port}"/>
<ora:deploy>
<ora:parameter name="workspace" value="${ws}"/>
<ora:parameter name="project" value="${pr}"/>
<ora:parameter name="profile" value="${pf}"/>
2) https://github.com/tkleiber/de.kleiber.ciroot
28

weblogic.Deployer-Aufrufe in sub_build.xml:
<path id="wldeploy.path">
<fileset file="${wls.dir}/server/lib/weblogic.jar"/>
<fileset file="${wls.dir}/server/lib/webservices.jar"/>
</path>
<taskdef name="wldeploy"
classname="weblogic.ant.taskdefs.management.WLDeploy"
<classpath refid="oracle.wldeploy.path"/>
</taskdef>
<wldeploy action="undeploy" name="${nm}" library="${library}"
user="${user}" password="${oracle.wls.password}"
failonerror="false" adminurl="${url}" targets="${tg}"
allversions="true"/>
<wldeploy action="deploy" name="${nm}" source="${ear_or_jar}"
library="${library}" user="${user}" password="${pw}"
failonerror="true" upload="true" adminurl="${url}" targets="${tg}"
plan="${plan}" appversion="${build.number}"/>
29
Buildautomatisierungs-Tools: ANT - Deploy

Buildautomatisierungs-Tools: ANT - MDS
Deployment bei MDS fordert Repository-Information
Einziger automatischer Weg: Modifikation EAR per WLST
<exec executable="${wlst}" failonerror="true">
<arg value="addMdsRepository.py ${ear} ${admin_url}
${jdev.system.dir}"/>
WLST Skript addMdsRepository.py:
archive=getMDSArchiveConfig(fromLocation=sys.argv[1])
if sys.argv[2]=='t3://localhost:7101':
archive.setAppMetadataRepository(repository='mds-local',
partition='p', type='file', path=sys.argv[3] +
'DefaultDomainmds-local')
else:
archive.setAppMetadataRepository(repository='mds-ikb',
partition='p', type='DB', jndi='jdbc/mds/ikb')
archive.save()
30

Build-Automatisierungs-Tools: ANT - IKB
Deployment Ablauf bei der IKB
-Build aller
-ADF Libraries
-Anwendungen incl. MDS Konfiguration
-Undeploy aller Anwendungen
-Deploy aller Anwendungen
Build bei Commit s.o. ohne Deployment
Modularer Aufbau der ANT-Targets
alle Targets laufen auf Win7 und Linux
Für Entwickler: lokaler Build/Deployment eines Pillars
! ojdeploy Returncode = 0, wenn nichts zu verarbeiten!
 mittlerweile umgestellt auf exec-Task
31

Wir wissen nicht, wann der Fachbereich abnimmt! Wir
müssen Projekte mit fixem Einsatztermin realisieren!
Trotzdem wollen wir agil regelmäßig Artefakte releasen.
Wir brauchen einen speziellen
Branching Prozess!
32

Branching Prozess - Entscheidungkriterien
Nicht abgenommener Code darf Release nicht blockieren
Ebenso nicht fertiggestellter Code
Projekte sind meist nicht auf einen Pillar beschränkt
Integration / automatischer Test der Gesamtanwendung
Unabhängiger Test und Deployment von Code/Projekten
 2 Möglichkeiten: Branching oder Feature Toggles
 Nutzwertanalyse: spez. Branching Prozess erforderlich
Feature Toggles scheiterten an „deklarativem“ ADF:
-Viele Daten liegen als xml-Konfigurationen vor
-Framework kann Toggles dort nicht erkennen/zerstört sie
33

Continuous Integration
Integrationstest
Paket 2_2
Branching Prozess - Modell
1) Pakete können sein: User Stories, Projekte, Hotfixes
34
Trunk
Abnahmetest
Systemtest
Paket 1_1
Paket 2_1
Release 4.0.0 Release 5.0.0
Branch
Merge
Develop
Release 4.1.0
Risiko: aufgrund Reihenfolge/Merging unterschiedliche
Stände pro Testbranch möglich
Toggles zum Verbergen nicht einzusetzender Funktionen

35
Wir wollen unsere Applikationen regelmäßig bauen. Wir
wollen nicht manuell den Build starten! Wir wollen
schnelles Feedback über Fehler bekommen!
Wir brauchen einen
Continuous Integration Server!

CI Server: Jenkins - Überblick
Kostenlos, aber kostenpflichtiger Support möglich
Große Community
Mehrere Hunderte Plugins
im Einsatz bei IKB: Ant, EnvInject, Clone Workspace,
TaskScanner, Findbugs, PMD, Checkstyle, JaCoCo.
Email Extension u.a.
1) http://de.slideshare.net/tkleiber/qualittssicherung-in-adf-projekten-der-ikb-deutschen-industriebank
36

CI Server: Jenkins - Jobs
Automatischer Build nach jedem Commit auf CI-Branch
Kritische Regeln vor Build führen zum Abbruch
Statische Codeanalyse nach jedem Build
Tests nach jedem Build (z.B. Unit-Tests)
Deployment willentlich nach Entscheidung Tester
Tests nach jedem Deploy (z.B. GUI-Tests mit Selenium)
37

38
Wenn wir Konventionen oder Regeln nicht einhalten,
wollen wir nicht suchen müssen, um den Fehler zu finden.
Wir brauchen für alles, was wir
automatisch prüfen können, Code-Checks.

Code Checks: PMD
PMD nutzbar über ANT sowohl im Batch & JDeveloper
Großer Umfang mitgelieferte Regeln
Einfach konfigurierbar
Einfach erweiterbar (Java, XPath)
Unterdrückung von Meldungen im Code möglich
Unterstützt u.a. Java und XML
ADF Metadaten sind in XML Dateien abgelegt
39

Code Checks: PMD - Anpassungen
Anpassung für JDeveloper/ADF-Dateien erforderlich in
%pmd-src%srcmainjavanetsourceforgepmdlangLanguage.java
XML("XML", null, "xml", XmlRuleChainVisitor.class, "xml"),

XML("XML", null, "xml", XmlRuleChainVisitor.class, "xml", "jws", "jpr", "cpx",
"xcfg", "dcx", "jpx"),
PMD bauen (hier Windows)
cd %pmd-src%
set JDEV_HOME=C:OracleJDev111240
set JAVA_HOME=%JDEV_HOME%jdk160_24
%JDEV_HOME%jdeveloperapache-maven-2.2.1binmvn clean package
1) https://develishdevelopment.wordpress.com/2013/07/02/write-adf-static-code-analysis-rules-with-pmd-and-running-these-in-jdeveloper/
40

Code Checks: PMD - Regeldefinition
Application Module soll auf JDBC Datasources basieren:
<rule name="OracleAdfAmShouldNotBaseOnJdbcUrl" language="xml"
message="ADF application module configurations should based on
JDBC data sources, not on JDBC URLs"
class="net.sourceforge.pmd.lang.rule.XPathRule">
<priority>1</priority>
<properties>
<property name="xpath">
<value>
<![CDATA[
/BC4JConfig/AppModuleConfigBag/AppModuleConfig[@JDBCName]
]]>
</value>
</property>
</properties>
</rule>
41

Code Checks: PMD - kritische IKB Regeln
Namens-Konvention für JDBC Datasoures
Standard Exceptionhandler im Data Binding
Optimistic Locking gesetzt
Keine DB Connection Details in ADF Libraries exportieren
Stop bei Validierungsfehlern in ADF Libraries
Compiler Encoding UTF8
Regeln für Injection AMIS ADF Performance Monitor
Taskflow muss von Template ableiten (wg. Exc. Handling)
Keine Abhänigkeiten vom Build Output/Deployment-Profil
Unnötige Exports (ADF Runtime etc. im WLS vorhanden)
1) http://www.amis.nl/adfperformancemonitor
42

Das Bauen/Deployen soll noch schneller werden!
Vielleicht! Bald!
Wir müssen
• nur geänderten Code bauen
• Ringschlüsse eliminieren
• Artefakte wiederverwenden
43

Geschwindigkeit - nur geänderten Code bauen
… oder solchen der von der Änderung abhängig ist
Abhängigkeiten automatisch ermittelbar?
azyklischer Graph als Reihenfolge Build/Deployment
Dieser muss frei von Ringschlüssen sein
PoC über Workspaces hinweg zur Ermittlung von
-Graphen
-Ringschlüssen
-geänderten Sourcen zwischen 2 SVN Revisionen
44

Geschwindigkeit – Ringschlüsse eliminieren
45
Die Auflösung ist Voraussetzung für weitere Aktionen
Problem: ktms darf aktuell nicht angefasst werden, da es
durch eine Standardsoftware abgelöst werden soll

Geschwindigkeit - azyklischer Graph
46
Implementierung noch nicht
vollständig
Eventuell kann das nach
einer Migration Maven
leisten?

Geschwindigkeit - Artefakte wiederverwenden
47
… aus dem Build
Kernprinzip Continuous Delivery
wg. IKB Branching nur eingeschränkt anwendbar
zumindest Build Artefakte pro CI Branch vom Deployment
wiederverwenden
Umsetzung über Jenkins Plugins „Build Pipeline“ und
„Clone Workspace“ geplant
statt Artefakt Repository derzeit Ablage in dediziertem
Artefakte-Workspace

Geschwindigkeit - Verfügbarkeiten maximieren
48
Shared Libraries:
-ADF Libraries werden separat auf WLS deployed
-Versionierbar, neue Version zusätzlich deploybar
-Ungenutzte Versionen undeployen
-Bei IKB aktuell nicht mehr benutzt, aber wieder geplant
Hot Deployment
-Applikationen basieren auf letzter Version Shared Libs
-Selbe Version wird redeployed und nutzt dann neue
Versionen der Shared Libs
-Neue Sessions nutzen neue Applikationsversion

Fazit
49
ADF Build & Deployment hat verschiedenste Aspekte
Automatisierung ist wesentlich
Kein Anspruch auf Vollständigkeit
IKB spezifisch, so oder ähnlich aber wiederverwendbar
Immer noch großes Optimierungspotenzial
„Bob the Builder“ kehrt wieder in
„Sammler des Wissens“ - Maven für ADF

Bob the Builder - Build & Deploy von ADF Enterprise Anwendungen

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Bob the Builder - Build & Deploy von ADF Enterprise Anwendungen

Ähnlich wie Bob the Builder - Build & Deploy von ADF Enterprise Anwendungen (20)

Bob the Builder - Build & Deploy von ADF Enterprise Anwendungen