The regulatory system has more and more influence on our software development. Regulatory authorities, external and internal Auditors are increasingly examining our IT and not longer only our business processes and balance sheets. Some of them have better trained IT experts as we can find on the free market. General standards such as ISO/IEC 2700X but also banking-specific standards such as BAIT and MaRisk now pose challenges that generally only large software manufacturers know. Approximately 40 % of our projects are now regulatory-driven. Therefore, we are currently redefining our development process in order to implement the following requirements, among others * Unchangeability of the tested artefacts after the test * Functional segregation * Detection of accidental changes or intentional manipulations of the application The lecture shows the vision of such a safe process. It shows the current status of implementation in SOA and ADF development, for example: Migration of version management to GIT in Atlassian BitBucket Application and selection criteria for a branching model Mandatory code reviews in Atlassian BitBucket Build and Deployment Pipelines in Jenkins Automatic documentation in JIRA Issue via Bitbucket and Jenkins. Maybe you too can minimize the additional work and continue to work agile to meet such requirements.

1. Torsten Kleiber, DOAG 2018 Nürnberg, 21.11.2018
Regulatorik: Abseits ist, wenn der Schiedsrichter pfeift

2. IKB – Die Unternehmerbank
IKB im Überblick
Bank für den Mittelstand
Mid Caps Deutschland
 Mid Cap-Wachstum deutlich höher als deutsche Volkswirtschaft
 Starkes inländisches Umsatzwachstum mit hohem Potenzial für internationale
Expansion
 Operative Margen über den Konjunkturzyklus hinweg widerstandsfähig
2
Umsatzwachstumspotenzial, Mid Caps Deutschland
Unterdurchschnittlich
DurchschnittlichHochSehr hoch
IKB-Standorte
 Einzig bundesweit agierende Bank, die ausschließlich Firmenkunden begleitet
 Starke Kreditexpertise
 Langjährige Erfahrung im Fördermittelkreditgeschäft
 Kapitalmarkt- und Beratungsdienstleistungen
 Zugang zu mehr als 4.000 Fokuskunden
 Finanzierungspartner für Mittelstand seit mehr als 90 Jahren
 817 Mitarbeiter (VAK)
 Aktionär: Lone Star 100 %
 Bilanzsumme: 17,2 Mrd. €
 CET 1 Ratio: 11,6 % fully loaded
 Leverage Ratio: 7,0 % fully loaded

3. Abseits ist, wenn der Schiedsrichter pfeift
Franz Beckenbauer
Die Abseitsstellung eines Spielers stellt an sich noch kein Vergehen dar.
Ein Spieler befindet sich in einer Abseitsstellung, wenn er der gegnerischen
Torlinie näher ist als der Ball und der vorletzte Gegenspieler
Ein Spieler befindet sich nicht in einer Abseitsstellung
 in seiner eigenen Spielfeldhälfte oder
 auf gleicher Höhe mit dem vorletzten Gegenspieler oder
 auf gleicher Höhe mit den beiden letzten Gegenspielern«
Abseits im Fußball
Der (eine) Schiedsrichter kann das Abseits nur pfeifen, wenn der Spieler aktiv am Spiel
teilnimmt oder einen Vorteil aus der Abseitsposition zieht
1) https://upload.wikimedia.org/wikipedia/commons/7/74/Franz_Beckenbauer_2007.jpg
2) https://gfds.de/13-abseits-ist-wenn-der-schiedsrichter-pfeift/
3

4. Abseits in der Softwareentwicklung
Mehr Schiedsrichter als Spieler bringen die IT ins Abseits, teilweise bereits bevor sie aktiv
wird und auch wenn noch kein nachgewiesener Nachteil entstanden ist.
4
Grundschutzkataloge
ISO/IEC 2700X
PrüfungenPrüfungen
BAIT
MaRisk
GDPR / DSGVO
Gesetzgeber und Behörden Aufsichtsbehörden
Wirtschaftsprüfer Interne Prüfer (Revision, Security,
Datenschutz)
Prüfungen
IT

5. Beispiel: Aufgabentrennung
5
Quelle Beschreibung
BAIT 5 Das Institut hat insbesondere das Informationsrisikomanagement, das Informations-
sicherheitsmanagement, den IT-Betrieb und die Anwendungsentwicklung quantitativ
und qualitativ angemessen mit Personal auszustatten.
BAIT 6 Interessenkonflikte und unvereinbare Tätigkeiten innerhalb der IT-Aufbau- und IT-
Ablauforganisation sind zu vermeiden. Interessenkonflikten zwischen Aktivitäten, die
beispielsweise im Zusammenhang mit der Anwendungsentwicklung und den
Aufgaben des IT-Betriebs stehen, kann durch aufbau- oder ablauforganisatorische
Maßnahmen bzw. durch eine adäquate Rollendefinition begegnet werden.
Interne
Revision
Einzelne Entwickler übernehmen die Administration der Systeme und besitzen auf Ebene
des Betriebssystems und der Datenbank- und Applikationsserver weitreichende
Berechtigungen. Administrative Berechtigungen von Entwicklern auf Datenbank- und
Serverebene sowie in Deployment-Tools sind zu entziehen.
Administration in Entwicklungsteam ist möglich, wenn Personen nur noch diese Rolle
ausüben oder über Code Review geprüft werden. Fehlende Kapazitäten sind aufzubauen.

6. Beispiel: Anwendungsentwicklung
Diese Anforderungen sind nicht mehr rein organisatorisch lösbar ohne in eine Nachweis-
pflicht zu geraten. Im folgenden wird die Umsetzung bei der IKB beschrieben.
6
Quelle Beschreibung
BAIT 39 Im Rahmen der Anwendungsentwicklung müssen Vorkehrungen getroffen werden, die
erkennen lassen, ob eine Anwendung versehentlich geändert oder absichtlich
manipuliert wurde. Eine geeignete Vorkehrung unter Berücksichtigung des
Schutzbedarfs kann die Überprüfung des Quellcodes im Rahmen der
Anwendungsentwicklung sein.
Interne
Revision
In den Deployment-Tools besteht die Möglichkeit für Entwickler, nach Abnahme
Codebestandteile zu verändern und ohne weitere Kontrollen in Produktion zu bringen.
Es ist sicherzustellen, das der Code nach der Abnahme nicht mehr verändert
werden kann.

7. KreDa (Kredit und Darlehensverwaltung und vieles mehr)
Ausgangslage Architektur KreDa, Versionierung, Branching, Build & Deploy
7
Oracle Forms & Reports
PVCS, kaum Branches, UC4
Oracle ADF
Subversion, langlebige Feature
Branches & Cherry Picking, Jenkins
Jobs
Oracle PL/SQL / Views
PVCS, kaum Branches, UC4
Oracle SOA
Suite Mediator
Subversion,
langlebige
Feature
Branches &
Cherry Picking,
Jenkins Jobs
Oracle Datenbank
PVCS, keine Branches, UC4
AndereAnwendungen

8. Neues Version Control System (VCS): Git + Atlassian Bitbucket
Übernahme Einzel-Commits bei Merge inklusive Autor zur Änderungsdokumentation
Unterstützung und Erzwingen Code Review
VCS-Server mit Administrationsoberfläche
Konfigurierbares Branching Modell
Dezentrale Versionierung lokal bei Entwickler
Schneller Zugriff
Migration von Subversion nach Git über Atlassian-Tools
Client Git für Windows und Atlassian Sourcetree
JDeveloper Git-Client nicht komfortabel
SSO noch nicht umgesetzt
 Migrationsunterstützung für Serena PVCS Version Manger
Einführung von GIT und Bitbucket ist die Voraussetzung für folgende Tools und Prozesse.
8

9. Monorepo: Technologien in selben Code-Repository, Entwicklung in einem Branch/Issue möglich
Trunk Based Development
 Code beginnend mit dem Integrationstest im master (=trunk) eingecheckt
 kein Cherry Picking, Änderungen laufen durch alle Umgebungen
 kurzlebige Feature-/Bugfix-Branches
 Release-Branches für Bugfixes
Feature Toggles / Branch by Abstraction
Monorepo und Trunk Based Development sind Standards
Isolierte kleinteilige Issues erforderlich, Abhängigkeiten beachten!
Features vollständig beschrieben vor Entwicklungsbeginn, sonst lokales RAD mit Kunde erforderlich
Neue Anforderungen sind neue Issues!
Abnahmeverpflichtung Fachbereich vor Merge erforderlich, dann erst Deployment/Test
Fehlende Abnahme  Reverse Merge  neuer Regressions-Test
Git-Struktur/Branching-Modell sind Voraussetzung für die Umsetzung. Durch die
erforderliche neuen Prozesse ändern sich auch massiv die Prozesse der Fachbereiche!
Branching Strategie: Trunk Based Development auf Basis eines Monorepo
9

10. Monorepo
 Alle für ein Feature erforderlichen Änderungen sind in einem Issue/Branch durchführbar.
10

11. Trunk Based Development
Änderungen durchlaufen für Deployment immer den Master. Ausnahme: Sonderfälle bei
Bugfixes (z.B. bei geändertem Datenmodell evtl.. auf Master nicht mehr testbar)
11
 Ablauf zeitlich nach unten und Umgebung nach rechts
 Branches
- master (=Subversion Trunk)
- feature/bugfix für Entwicklung
- master, release/* nur über Pull Request änderbar
- master: fortlaufende Integration von Änderungen für
Test und Einsatz
- release: 1 letzter Produktionstand für Bugfixes
 tags: durch Jenkins vergeben für
- Version: v<Jahr>.<Monat>.<Master>.<Bugfix>
- Umgebung
- e,a,p: Einsatztermin der Version pro Stage
- Entwicklung, Abnahme, Produktion:
Kennzeichnung des aktuellen Stands pro Stage

12. Pipelines: Buildprozess als Code eingecheckt in das Monorepo inklusive Code Review
Multi-Branch-Pipelines: Build für alle Branch-Typen und Pull Requests
- Pipeline einmalig vom Administrator in Jenkins geladen und konfiguriert
- Code durchläuft selbe Pipeline
- frühe Integration und Stabilität des Master-/Release-Branches durch Build Pull Reuests
- nur im Master-/Release-Branch erfolgen Deployments nach Abfrage durch autorisierte Benutzer
automatischer Start bei Änderung des Codes
Funktionstrennung durch administrative Ablage von Passworten etc. in Jenkins
Continuous Delivery  Release jederzeit einsetzbar, wenn getestet
Jenkins Integration mit Atlassian JIRA und Bitbucket
Aufräumen überholter/alter Pipeline-Instanzen noch manuell, da Milestone-Plugin bug-behaftet
Jenkins Pipelines as Code: Multi-Branch-Pipelines
Build und Deployment ist als Code dokumentiert, versioniert und unterliegt dem Code
Review. Passworte der Laufzeit-Umgebung werden zur Funktionstrennung in Jenkins
abgelegt. Branches und Pull Requests werden automatisch gebaut.
12

13. Multi-Branch-Pipelines
13
Änderungen durchlaufen die Pipeline, nur in Master-/Release-Branches erfolgt Deployment.

14. Pipeline für ADF und SOA
In der Präsentation wird meist nur eine vereinfachte Demo-Pipeline gezeigt, das ist die
aktuelle reale Pipeline.
14

15. Code-Review: Atlassian Bitbucket über Pull Requests
Pull Requests dienen der Abstimmung und Freigabe von Änderungen
Code-Review und Merge sind konfigurierbar
Branches master und release/* nur durch Pull Requests änderbar
Merge-Cecks: mdst. 1 Reviewer erforderlich, Alle Reviewer stimmen zu, mdst. 2 erfolgreiche Builds
Ersteller des Pull Requests kann nicht Reviewer werden
Differenzsicht mit Kommentierungs-/Interaktions-Möglichkeiten
Reviewer muss den Pull Request vor dem Merge explizit als erfolgreich reviewed markieren
Merge kann jeder Berechtigte durchführen, also auch der Reviewer
Integriert mit Atlassian JIRA
Trunk Based Development o.ä. Branching Modell erforderlich
git push –author: abweichende Autoren verhindern  eigenes Plugin entwickelt
 Code Review ist Engpass  separater Status im JIRA Kanban Board
 Diff-Sicht bei Binärsourcen wie Oracle Forms & Reports?
Unabhängig von den Autoren der Einzel-Commits im Pull-Request sind mindestens 2
Personen für die Freigabe erforderlich
15

16. Commits/Push
Developmentprozess: Grafisch
Issue
Feature-/Bugfix-
Branch
Pull Request
Code Review
Merge
Build Feature-/Bugfix-
Branch
Build Pull Request
Build Master-/Relase
Branch
Deploy Master-/Relase
Branch
Integrations-Test
Acceptance-Test
Produktion
Code
Master
Master
Master, Release
Build Feature-/Bugfix-
Branch
SOA Composites
Integrations-Test
16

17. Erzeugen eines Feature Branches
Aus dem JIRA Issue wird ein Branch angelegt, der direkt in Jenkins gebaut wird.
17

18. automatischer Build des Branchs
Nach dem Push von Commits läuft ein weiterer Build des Branches in Jenkins an.
18

19. Anlegen Pull Request
19
Üblicherweise vom letzten Entwickler wird der Pull Request angelegt.

20. automatischer Build Pull Request
Nach kurzer Zeit läuft der erste Build des Pull Request in Jenkins an.
20

21. Review durch Anleger nicht möglich, Merge nicht möglich
Der Anleger kann sich nicht als Reviewer zuordnen, ein Merge ist noch nicht möglich.
21

22. als anderer Benutzer Zuordnung als Reviewer, Merge nicht möglich
Ein anderer Entwickler kann sich als Reviewer zuordnen, um das Review durchzuführen.
22

23. Korrektur von Code im Branch
Korrekturen im Branch aktualisiert den Pull Request und baut Branch und Pull Request.
23

24. Freigabe und Merge
Der Reviewer muss den Pull Request genehmigen, erst danach kann gemerged werden.
24

25. automatischer Build und Deployment des Master-Branchs
Der Build des Masters läuft an, wartet aber auf eine Bestätigung des Deployments.
25

26. Commit Historie mit Tags Master-Branch
26
Man sieht, wann die Version in welche Umgebung gegangen und ob sie noch aktuell ist.

27. Pull Request Historie Übersicht
Es werden Teil-Informationen über Merge-Ziel und Merge-Checks gezeigt.
27

28. Pull Request Historie Details
Es wird die gesamte Historie des Pull Requests gezeigt.
28

29. Entwicklungshistorie in JIRA-Issue
29
Commits und Pull Requests werden für jeden berechtigten JIRA User angezeigt, gelöschte
Branches nicht mehr. Für weitere Details benötigt man Berechtigungen in Bitbucket.

30. Fazit
Ausgangslage
Die Regulatorik stellt die IT ins Abseits, obwohl funktionierende Software geliefert wird.
Regulatorische Anforderungen
- stehen teilweise im Widerspruch zum Stand der Technik (z.B. DevOps)
- können mit weniger oder mehr Aufwand gelöst werden
Ziel: weitgehend automatisierte Lösungen, um den Mehraufwand für IT gering zu halten
Umsetzung der Beispielanforderungen
Funktionstrennung zwischen Entwicklung und Administration, Zugänge geändert
Entwicklungsprozess wurde geändert um
- sicherzustellen, das der Code nach dem Test nicht mehr verändert werden kann
- verpflichtend ein Code Review durchzuführen, um Schadcode frühzeitig zu erkennen
Tools und Prozesse wurden eingeführt und angepasst (Git; Git for Windows; Atlassian Bitbucket,
JIRA & Sourcetree; Monorepo & TBD; Jenkins Multibranch Pipelines as Code; Code Review)
Prozess ist für ADF- und SOA-Entwicklung produktiv, PL/SQL, Forms & Reports stehen noch aus
30

31. Über mich
Torsten Kleiber
Software-Architekt, Entwickler, DevOps, Administrator
Kreditplattform
Seit 19 Jahren bei der IKB
22 Jahre Erfahrung in
PL/SQL
Forms & Reports
ADF
SOA Mediator
Architektur & Infrastruktur
Fusion Middleware
Development Tools
Development Lifecycle
31

32. Fragen & Antworten
32