Home >Software >Qualitätssicherung in ADF Projekten der IKB Deutschen Industriebank AG
Qualitätssicherung in ADF Projekten der IKB Deutschen Industriebank AG
Date post:05-Dec-2014
Category:Software
View:1,008 times
Download:0 times
Share this document with a friend
Description:
Bei der Nutzung von ADF im Unternehmensumfeld wird man schnell erschlagen von der Flle der Entscheidungen z. B. zu Architektur, zur Anwendung von Best Practices und Regeln. Generell gilt das geflgelte Wort one size does not fit all: Jede der getroffenen Vorgaben ist fr das Unternehmen, die Applikation oder sogar das einzelne Codefragment zu prfen und zu hinterfragen. Die Nichtanwendung im Einzelfall sollte dokumentiert werden. Wenn man sich denn einmal fr einzuhaltende Regeln entschieden hat, wie prft man diese an verschiedenen Stellen im Entwicklungsprozess? Wie sorgt man dafr, dass der Entwickler diese Regeln anwendet, ohne sich stndig weiterentwickelnde Entwicklerhandbcher durchlesen zu mssen? Der Vortrag geht exemplarisch auf die in der ADF Entwicklung der IKB eingefhrten Tools, Prozesse und Regeln ein, um eine qualitative Verbesserung der Code Basis zu erreichen und stellt genutzte Mglichkeiten zur Durchsetzung kritischer Regeln vor. Bestandteile der aktuellen Lsung sind die Prfung der Regeln im: - JDeveloper mit - Skripten fr PMD, Findbugs und Checkstyle zur statischen Codeanalyse - der integrierten Task View - der JUnit Extension - Skripten fr JaCoCo zur Testabdeckung - Continous Integration Server Jenkins mit den Plugins - PMD, Findbugs und Checkstyle zur statischen Codeanalyse - Task Scanner zur Prfung offener Punkte - Junit zur Testausfhrung - JaCoCo zur Testabdeckung
Transcript:
  • 1. Qualittssicherung in ADF Projekten der IKB Deutsche Industriebank AG Torsten Kleiber, DOAG Development, 4.6.2014
  • 2. IKB Bank des Mittelstands IKB im berblick Leistungsspektrum Regionale Prsenz 1) Zzgl. 18.000 Kunden im Leasing-Geschft 2) Stand: 30. September 2013 2 Seit 90 Jahren Finanzierungspartner des Mittelstands 2.500 Kunden in Deutschland und Europa1) Aktionre: Lone Star 91,5 %, Streubesitz 8,5 % ca. 1.500 Mitarbeiter Bilanzsumme: 25,8 Mrd.2) Kernkapitalquote: 11,21 %2) Mailand London Paris Madrid Mnchen Stuttgart Frankfurt Dsseldorf (HQ) Berlin Hamburg Frdermittel Konsortial- finanzierung Leasing Equity Capital Markets Advisory M&A Corporate Finance Risikomanagement Debt Advisory Derivate Sales & Trading Kredit Bilaterale Finanzierung Capital Markets Debt Capital Markets
  • 3. ber mich Torsten Kleiber Software Architekt, Entwickler Kreditplattform 15 Jahre IKB, 18 Jahre Oracle Erfahrung von Designer / Forms / Reports PL/SQL hin zu Architektur Fusion Middleware SOA Mediator ADF Development Tools Development Lifecycle Release Management 3
  • 4. Agenda 4 ADF in der IKB Warum und wie wird ADF in der IKB eingefhrt? Zielstellung QS Welche Ziele werden bei den QS untersttzenden Prozessen und Tools verfolgt? Toolauswahl IDE / CI Warum wurden welche IDE und welcher CI Server ausgewhlt? Statische Codeanalyse Welche Tools zur statischen Codeanalyse werden wie bei der IKB genutzt? Automatisierter Test Welche Tools fr den automatischen Test werden wie bei der IKB genutzt? Code Abdeckung Wie ermittelt man, wieviel und welcher Code getestet ist? Evaluierung Welche Tools befinden sich noch in der Evaluierung? Fazit Der aktuelle Stand in den ADF Projekten.
  • 5. ADF in der IKB Ausgangspunkt: Migration Eigenentwicklung zur Kredit und Darlehensverwaltung Forms & Reports ADF & ??? Entscheidung ADF hauptschlich wegen Strategie bei Oracle Fusion Applications > 500 Forms, > 60 Mens, > 40 Bibliotheken, > 350 Reports Ca. 50% der Module in englisch Startpunkt 2012 Migration 1 Eigenentwicklung MS Access ADF mit 6 Personen Gleichzeitig Einfhrung agiler Methoden (Kanban) Aktuell 16 Entwickler + 2 Tester + 3 Coaches (Opitz Consulting, esentri) Entwicklung neuer User Stories wenn mglich in ADF (SEPA, FATCA, ) Projekt zur Ablsung Forms & Reports ber ca. 3 Jahre Aktuell ADF Version 11.1.1.5, Migration nach 12c ist fr August 2014 geplant Internet Explorer als Browser gesetzt 5
  • 6. Zielstellung Qualittssicherung kontinuierliche qualitative Verbesserung der Code Basis keine 100%! Erlernen von Best Practices Prfen von Entscheidungen z.B. zu Architektur, Best Practices Konfiguration von gegebenen Regeln Erstellung von eigenen Regeln Dokumentation bewusster Abweichungen von Regeln im Code und Unterbindung der weiteren Verletzung Integration der Regeln in die IDE des Entwicklers Integration der Regeln in den Continuous Integration Prozess Konsequenzen im Delivery-Prozess bei Verletzung kritischer Regeln automatischer Regressionstest im Backend und der GUI Messung der Codeabdeckung durch Tests 6
  • 7. Toolauswahl IDE und Continuous Integration Server IDE - Standard ADF Stack (ADF BC, ADF Controller, ADF Faces) in der IKB, damit JDeveloper als IDE gesetzt. Continuous Integration Server - zunchst Oracle Hudson als CI Server eingefhrt - Spezielle Anforderungen an Jobs durch Hudson nicht lsbar - Support bzw. ausreichende Weiterentwicklung konnte nicht beobachtet werden - Jenkins ist ein Fork von Hudson nach der bernahme von Sun durch Oracle - Kostenlos, aber kostenpflichtiger Support mglich - Groe Community - 600+ Plugins - Umstieg auf Jenkins nach Prfung der Anforderungen in unter einem Tag 7
  • 8. Vorbereitungen Zentrale versionierte Ablage aller Tools (auer Jenkins Plugins) wegen Upgrades Kann sowohl fr JDeveloper als auch Jenkins verwendet werden Beispiel der Prsentations-Umgebung verfgbar auf: https://github.com/tkleiber/de.kleiber.ciroot.git 8
  • 9. Statische Codeanalyse - Tools Sucht / Prft Vor- / Nachteile Integrationen FindBugs PMD Checkstyle Bugs Potenzielle Probleme Bugs Nicht bentigten und suboptimalen Code berkomplizierte Ausdrcke Duplizierten Code (CPD) Coding Standards Nur Java Code Schwer konfigurierbar Schwer erweiterbar Unterdrckung von Meldungen im Code mglich, aber komplex Bytecode erforderlich Schnell Java, JSP, JSF, XML, XSL Einfach konfigurierbar Einfach erweiterbar (Java, XPath) Unterdrckung von Meldungen im Code mglich Nur Java Code Einfach konfigurierbar Einfach erweiterbar (Java) Unterdrckung von Meldungen im Code mglich Diverse IDEs Nicht JDeveloper ANT Maven Jenkins Hudson Diverse IDEs JDeveloper (rudimentr) ANT Maven Jenkins Hudson Diverse IDEs Nicht JDeveloper ANT Maven Jenkins Hudson Fazit: Die Tools decken verschieden Zwecke gut ab, sind im JDeveloper aber nur unzureichend integriert. 9
  • 10. Statische Codeanalyse Anpassungen PMD Aufgrund XML-Analyse und XPath-Regeln bot sich PMD fr eigene Regeln an Anpassung fr XML-Analyse von JDeveloper/ADF-Dateien 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 Datei in %ciroot%rootlibpmdlib mit der aus %pmd-src%target ersetzen 10
  • 11. Statische Codeanalyse Regeln (1) Standardregeln - Checkstyle: sun_checks.xml wird mit ausgeliefert - PMD: Verzeichnis rulesets in Source srcmainresources oder in pmd-x.x.x.jar Konfiguration, z.B. Checkstyle - Javadoc Tag Prfung ist bei privaten Variablen nicht erforderlich, wenn dafr kein Javadoc erzeugt werden soll (und die Namen selbstdokumentierend sind) 11
  • 12. Statische Codeanalyse Regeln (2) Neue Regeln, PMD: Application Modules sollen auf JDBC Data Sources basieren 1 /BC4JConfig/AppModuleConfigBag/AppModuleConfig[@JDBCName] 12
  • 13. Statische Codeanalyse Apache Ant nur fr PMD existiert fr JDeveloper ein rudimentres Plugin (gepflegt von mir) Checkstyle, PMD, FindBugs, JDeveloper in Version 11.1.1.5 und Jenkins untersttzen Ant Output in bestimmten Format ermglicht Sprung zum Source Code im JDeveloper Checkstyle und PMD erfllen Format, fr FindBugs wurde ein Request angelegt Also: allgemeines Ant-Skripts mit folgenden Anforderungen - Welche Prioritt der Regelverste soll angezeigt werden? - Wo liegen die zu analysierenden Source-Verzeichnisse oder Dateien? - Wo ist das Middleware- und JDeveloper-Verzeichnis? - Relative Pfade fr Wiederverwendbarkeit in JDeveloper und Jenkins - Einschrnkung auf Java- und ADF-Dateien - Ausfhrung von FindBugs immer auf mindestens dem Projekt zur Datei wg. Vermeidung False Positives bezglich Kopplungsregeln 13
  • 14. Statische Codeanalyse JDeveloper External Tool Tools External Tools New Type: Apache Ant Ant Buildfile: %ciroot%rootcheck.xml Selected Targets: all (Default) Properties: - external.tool.sources.dir: ${file.dir} - external.tool.sources.file: ${file.name} - external.tool.sources.file.extension: ${file.ext} - external.tool.project.dirname: ${project.dirname} - external.tool.workspace.dir: ${workspace.dir} Caption for Menu Items / ToolTip Text: Checkstyle, FindBugs and PMD this Integration: Alle Checkboxes 14
  • 15. Statische Codeanalyse Unterdrckung von Verletzungen Ziele - Dokumentierte Unterdrckung im Einzelfall - Bestimmte Dateimuster (z.B. generierte Dateien) von der Analyse filtern Fr die verschiedenen Tools gibt es verschiedene Arten der Unterdrckung, z.B.: - FindBugs: - Annotations (Hierzu muss FindBugs.jar in den Pfad genommen werden!): @edu.umd.cs.FindBugs.annotations.SuppressFBWarnings(value="", justification="Begrndung") - Konfiguration: Filter - PMD: - Annotations: @SuppressWarnings("PMD.") - Kommentare: //
Embed Size (px)
Recommended