Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
Torsten Kleiber, DOAG 2018 Nürnberg, 21.11.2018
Regulatorik: Abseits ist, wenn der Schiedsrichter pfeift
IKB – Die Unternehmerbank
IKB im Überblick
Bank für den Mittelstand
Mid Caps Deutschland
 Mid Cap-Wachstum deutlich höher...
Abseits ist, wenn der Schiedsrichter pfeift
Franz Beckenbauer
Die Abseitsstellung eines Spielers stellt an sich noch kein ...
Abseits in der Softwareentwicklung
Mehr Schiedsrichter als Spieler bringen die IT ins Abseits, teilweise bereits bevor si...
Beispiel: Aufgabentrennung
5
Quelle Beschreibung
BAIT 5 Das Institut hat insbesondere das Informationsrisikomanagement, da...
Beispiel: Anwendungsentwicklung
Diese Anforderungen sind nicht mehr rein organisatorisch lösbar ohne in eine Nachweis-
pf...
KreDa (Kredit und Darlehensverwaltung und vieles mehr)
Ausgangslage Architektur KreDa, Versionierung, Branching, Build & D...
Neues Version Control System (VCS): Git + Atlassian Bitbucket
Übernahme Einzel-Commits bei Merge inklusive Autor zur Ände...
Monorepo: Technologien in selben Code-Repository, Entwicklung in einem Branch/Issue möglich
Trunk Based Development
 Co...
Monorepo
 Alle für ein Feature erforderlichen Änderungen sind in einem Issue/Branch durchführbar.
10
Trunk Based Development
Änderungen durchlaufen für Deployment immer den Master. Ausnahme: Sonderfälle bei
Bugfixes (z.B. ...
Pipelines: Buildprozess als Code eingecheckt in das Monorepo inklusive Code Review
Multi-Branch-Pipelines: Build für all...
Multi-Branch-Pipelines
13
Änderungen durchlaufen die Pipeline, nur in Master-/Release-Branches erfolgt Deployment.
Pipeline für ADF und SOA
In der Präsentation wird meist nur eine vereinfachte Demo-Pipeline gezeigt, das ist die
aktuelle...
Code-Review: Atlassian Bitbucket über Pull Requests
Pull Requests dienen der Abstimmung und Freigabe von Änderungen
Code...
Commits/Push
Developmentprozess: Grafisch
Issue
Feature-/Bugfix-
Branch
Pull Request
Code Review
Merge
Build Feature-/Bugf...
Erzeugen eines Feature Branches
Aus dem JIRA Issue wird ein Branch angelegt, der direkt in Jenkins gebaut wird.
17
automatischer Build des Branchs
Nach dem Push von Commits läuft ein weiterer Build des Branches in Jenkins an.
18
Anlegen Pull Request
19
Üblicherweise vom letzten Entwickler wird der Pull Request angelegt.
automatischer Build Pull Request
Nach kurzer Zeit läuft der erste Build des Pull Request in Jenkins an.
20
Review durch Anleger nicht möglich, Merge nicht möglich
Der Anleger kann sich nicht als Reviewer zuordnen, ein Merge ist ...
als anderer Benutzer Zuordnung als Reviewer, Merge nicht möglich
Ein anderer Entwickler kann sich als Reviewer zuordnen, ...
Korrektur von Code im Branch
Korrekturen im Branch aktualisiert den Pull Request und baut Branch und Pull Request.
23
Freigabe und Merge
Der Reviewer muss den Pull Request genehmigen, erst danach kann gemerged werden.
24
automatischer Build und Deployment des Master-Branchs
Der Build des Masters läuft an, wartet aber auf eine Bestätigung de...
Commit Historie mit Tags Master-Branch
26
Man sieht, wann die Version in welche Umgebung gegangen und ob sie noch aktuell...
Pull Request Historie Übersicht
Es werden Teil-Informationen über Merge-Ziel und Merge-Checks gezeigt.
27
Pull Request Historie Details
Es wird die gesamte Historie des Pull Requests gezeigt.
28
Entwicklungshistorie in JIRA-Issue
29
Commits und Pull Requests werden für jeden berechtigten JIRA User angezeigt, gelösc...
Fazit
Ausgangslage
Die Regulatorik stellt die IT ins Abseits, obwohl funktionierende Software geliefert wird.
Regulatori...
Über mich
Torsten Kleiber
Software-Architekt, Entwickler, DevOps, Administrator
Kreditplattform
Seit 19 Jahren bei der IKB...
Fragen & Antworten
32
Nächste SlideShare
Wird geladen in …5
×

von

Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 1 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 2 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 3 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 4 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 5 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 6 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 7 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 8 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 9 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 10 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 11 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 12 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 13 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 14 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 15 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 16 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 17 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 18 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 19 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 20 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 21 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 22 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 23 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 24 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 25 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 26 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 27 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 28 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 29 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 30 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 31 Regulatorics: Offside is when the referee whistles - DOAG 2018 Slide 32
Nächste SlideShare
What to Upload to SlideShare
Weiter
Herunterladen, um offline zu lesen und im Vollbildmodus anzuzeigen.

0 Gefällt mir

Teilen

Herunterladen, um offline zu lesen

Regulatorics: Offside is when the referee whistles - DOAG 2018

Herunterladen, um offline zu lesen

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.

Ähnliche Bücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

Ähnliche Hörbücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen
  • Gehören Sie zu den Ersten, denen das gefällt!

Regulatorics: Offside is when the referee whistles - DOAG 2018

  1. 1. Torsten Kleiber, DOAG 2018 Nürnberg, 21.11.2018 Regulatorik: Abseits ist, wenn der Schiedsrichter pfeift
  2. 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. 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. 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. 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. 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. 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. 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. 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. 10. Monorepo  Alle für ein Feature erforderlichen Änderungen sind in einem Issue/Branch durchführbar. 10
  11. 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. 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. 13. Multi-Branch-Pipelines 13 Änderungen durchlaufen die Pipeline, nur in Master-/Release-Branches erfolgt Deployment.
  14. 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. 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. 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. 17. Erzeugen eines Feature Branches Aus dem JIRA Issue wird ein Branch angelegt, der direkt in Jenkins gebaut wird. 17
  18. 18. automatischer Build des Branchs Nach dem Push von Commits läuft ein weiterer Build des Branches in Jenkins an. 18
  19. 19. Anlegen Pull Request 19 Üblicherweise vom letzten Entwickler wird der Pull Request angelegt.
  20. 20. automatischer Build Pull Request Nach kurzer Zeit läuft der erste Build des Pull Request in Jenkins an. 20
  21. 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. 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. 23. Korrektur von Code im Branch Korrekturen im Branch aktualisiert den Pull Request und baut Branch und Pull Request. 23
  24. 24. Freigabe und Merge Der Reviewer muss den Pull Request genehmigen, erst danach kann gemerged werden. 24
  25. 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. 26. Commit Historie mit Tags Master-Branch 26 Man sieht, wann die Version in welche Umgebung gegangen und ob sie noch aktuell ist.
  27. 27. Pull Request Historie Übersicht Es werden Teil-Informationen über Merge-Ziel und Merge-Checks gezeigt. 27
  28. 28. Pull Request Historie Details Es wird die gesamte Historie des Pull Requests gezeigt. 28
  29. 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. 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. 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. 32. Fragen & Antworten 32

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.

Aufrufe

Aufrufe insgesamt

20

Auf Slideshare

0

Aus Einbettungen

0

Anzahl der Einbettungen

1

Befehle

Downloads

0

Geteilt

0

Kommentare

0

Likes

0

×