Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Bob the Builder - Build & Deploy von ADF Enterprise Anwendungen

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige

Hier ansehen

1 von 50 Anzeige

Bob the Builder - Build & Deploy von ADF Enterprise Anwendungen

Herunterladen, um offline zu lesen

Das Team Kreditplattform der IKB entwickelt seit etwa 4 Jahren mit ADF. Wir deployen gegen den WebLogic Server. Mittlerweile arbeiten mittlerweile 15 Entwickler parallel an Projekten und Migrationen. Um dies zu gewährleisten wurden auch eine Menge Architekturentscheidungen neu gefällt und durch entsprechendes Refactoring umgesetzt.

Bereits mit dem ersten Lern-Projekt vor 4 Jahren kam das komplexe Thema Build- und Deployment auf. Da bisher kein Know-How vorhanden war stellte sich schnell die Frage, ob man das automatisieren kann. Aber wer sollte das machen – wir brauchten also „Bob“. Bob kümmert sich seitdem um alle Themen rund um Build und Deployment.
Im Vortrag werden seine bisherigen Entscheidungen und Vorgehensweisen besprochen, aber auch offene Ideen und Punkte angerissen:

- Build-Tools
- Deployment-Tools
- Build-Automatisierungs-Tools
- Branching
- Continuous Integration Server
- Konventionen über Konfigurationen
- Code-Checks
- Build/Deploy Geschwindigkeit
- Eleminieren von Abhängigkeiten
- Minimieren Build/Deployment-Zeiten
- Verfügbarkeiten maximieren

Das Team Kreditplattform der IKB entwickelt seit etwa 4 Jahren mit ADF. Wir deployen gegen den WebLogic Server. Mittlerweile arbeiten mittlerweile 15 Entwickler parallel an Projekten und Migrationen. Um dies zu gewährleisten wurden auch eine Menge Architekturentscheidungen neu gefällt und durch entsprechendes Refactoring umgesetzt.

Bereits mit dem ersten Lern-Projekt vor 4 Jahren kam das komplexe Thema Build- und Deployment auf. Da bisher kein Know-How vorhanden war stellte sich schnell die Frage, ob man das automatisieren kann. Aber wer sollte das machen – wir brauchten also „Bob“. Bob kümmert sich seitdem um alle Themen rund um Build und Deployment.
Im Vortrag werden seine bisherigen Entscheidungen und Vorgehensweisen besprochen, aber auch offene Ideen und Punkte angerissen:

- Build-Tools
- Deployment-Tools
- Build-Automatisierungs-Tools
- Branching
- Continuous Integration Server
- Konventionen über Konfigurationen
- Code-Checks
- Build/Deploy Geschwindigkeit
- Eleminieren von Abhängigkeiten
- Minimieren Build/Deployment-Zeiten
- Verfügbarkeiten maximieren

Anzeige
Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Andere mochten auch (20)

Anzeige

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

Aktuellste (20)

Anzeige

Bob the Builder - Build & Deploy von ADF Enterprise Anwendungen

  1. 1. Bob the Builder: Build/Deploy von ADF Enterprise Anwendungen Torsten Kleiber, IKB Deutsche Industriebank AG DOAG, 17.11.2015
  2. 2. 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.
  3. 3. Ü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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. 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) 1) https://docs.oracle.com/middleware/1213/jdev/user-guide/jdev-build-java-projects.htm#OJDUG5835 9
  10. 10. 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? 1) https://docs.oracle.com/middleware/1213/jdev/user-guide/jdev-build-java-projects.htm#OJDUG5781 10
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. Build-Tools: ojdeploy – Laufzeiten (2) 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"/> <parameter name="profile" value="pf"/> </deploy> <deploy> <parameter name="workspace" value="path1ws1.jws"/> <parameter name="profile" value="pf"/> </deploy> <deploy> <parameter name="workspace" value="path1ws2.jws,...,pathXwsX.jws"/> <parameter name="profile" value="pf"/> </deploy> </ojdeploy-build>
  17. 17. Build-Tools: ojdeploy – Laufzeiten (3) 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
  18. 18. 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
  19. 19. 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
  20. 20. 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 Aufruf mit buildfile und ojserver Aufruf mit buildfile separate Aufrufe mit ojserver separate Aufrufe benötigt man Einzel- aufrufe sollte Option -ojserver benutzt werden sonst ist Option -buildfile die bessere Wahl
  21. 21. Unsere Artefakte müssen magisch auf Standalone-Server verteilt werden? Können wir das schaffen? Bob der Baumeister sagt: Yo, wir schaffen das! Wir brauchen Deployment-Tools! 21
  22. 22. 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
  23. 23. Die Build- und Deployment-Tools müssen immer wieder in einer definierten Reihenfolge aufgerufen werden? Können wir das schaffen? Bob der Baumeister sagt: Yo, wir schaffen das! Wir brauchen Build-Automatisierungs-Tools! 23
  24. 24. 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
  25. 25. 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
  26. 26. 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. 1) https://docs.oracle.com/middleware/1213/jdev/user-guide/jdev-build-java-projects.htm#OJDUG5847 26
  27. 27. 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 1) https://docs.oracle.com/middleware/1213/jdev/user-guide/jdev-build-java-projects.htm#OJDUG5842 27
  28. 28. 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"> <!-- Workaround ant task nicht verfügbare ojdeploy Parameter--> <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}"/> 1) https://docs.oracle.com/middleware/1213/jdev/user-guide/jdev-build-java-projects.htm#OJDUG5842 2) https://github.com/tkleiber/de.kleiber.ciroot 28
  29. 29. 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
  30. 30. 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
  31. 31. 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
  32. 32. Wir wissen nicht, wann der Fachbereich abnimmt! Wir müssen Projekte mit fixem Einsatztermin realisieren! Trotzdem wollen wir agil regelmäßig Artefakte releasen. Können wir das schaffen? Bob der Baumeister sagt: Yo, wir schaffen das! Wir brauchen einen speziellen Branching Prozess! 32
  33. 33. 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
  34. 34. 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. 35. 35 Wir wollen unsere Applikationen regelmäßig bauen. Wir wollen nicht manuell den Build starten! Wir wollen schnelles Feedback über Fehler bekommen! Können wir das schaffen? Bob der Baumeister sagt: Yo, wir schaffen das! Wir brauchen einen Continuous Integration Server!
  36. 36. 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
  37. 37. 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) 1) http://de.slideshare.net/tkleiber/qualittssicherung-in-adf-projekten-der-ikb-deutschen-industriebank 37
  38. 38. 38 Wenn wir Konventionen oder Regeln nicht einhalten, wollen wir nicht suchen müssen, um den Fehler zu finden. Können wir das schaffen? Bob der Baumeister sagt: Yo, wir schaffen das! Wir brauchen für alles, was wir automatisch prüfen können, Code-Checks.
  39. 39. 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
  40. 40. 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/ 2) http://de.slideshare.net/tkleiber/qualittssicherung-in-adf-projekten-der-ikb-deutschen-industriebank 40
  41. 41. 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
  42. 42. 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
  43. 43. Das Bauen/Deployen soll noch schneller werden! Können wir das schaffen? Bob der Baumeister sagt: Yo, wir schaffen das! Vielleicht! Bald! Wir müssen • nur geänderten Code bauen • Ringschlüsse eliminieren • Artefakte wiederverwenden 43
  44. 44. 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
  45. 45. 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
  46. 46. Geschwindigkeit - azyklischer Graph 46 Implementierung noch nicht vollständig Eventuell kann das nach einer Migration Maven leisten?
  47. 47. 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
  48. 48. 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
  49. 49. 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
  50. 50. Fragen & Antworten 50

×