Migrate all repos into monorepo context folders
Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)
Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.
This commit is contained in:
@@ -0,0 +1,29 @@
|
||||
# 10.2 Team Migration
|
||||
|
||||
Version: 9 | Last modified: 2026-01-29T07:11:53.943+01:00
|
||||
Source: confluence page ID 525205609
|
||||
|
||||
---
|
||||
|
||||
Team Migration ab 2026:
|
||||
|
||||
 | Team Migration | Status |
|
||||
1
|
||||
| Markus Fritzsche (BA)Â
|
||||
| Extern angestellt |
|
||||
2 | Jonas Spiegel (ScM) | DB Systel |
|
||||
3 | Michael Mats (BA) | DB Systel Team DigiSec |
|
||||
4 | Feyzi Erden (RE) | DB Systel Team HEROS |
|
||||
5 | Georgios Chatziefstratiou (Dev) | DB Systel Team DASÂ (ab 2026) |
|
||||
6 | Sebastian Menrath (Dev) | Extern angestellt |
|
||||
7 | Hüseyin Korkut (Dev) | Extern angestellt |
|
||||
8 | Alexandra Thöne (UX) | Extern angestellt |
|
||||
9 | Anais Casanova (Test) | Extern angestellt |
|
||||
10 | Gael Tchatchou (Dev) | Extern angestellt |
|
||||
11 | Khalid Aaliuate (Dev) | DB Systel Team TPT |
|
||||
12 | Mads Kristian Hansen (Dev) | DB Systel Team Tops |
|
||||
13 | N.N. (Dev) | - |
|
||||
14 | Kouassi Sepenou Klousseh (QA) | DB Systel Team A4DB |
|
||||
15 | Kenan Esau (Dev) | Extern angestellt |
|
||||
16 | Michael Haslauer (Dev) | Extern angestellt |
|
||||
17 | Rainer Schuster (Dev) | Extern angestellt |
|
||||
@@ -0,0 +1,12 @@
|
||||
# 2.2 APN Beteiligte Teams
|
||||
|
||||
Version: 5 | Last modified: 2026-01-15T14:43:31.872+01:00
|
||||
Source: confluence page ID 513446330
|
||||
|
||||
---
|
||||
|
||||
DB InfraGOÂ ART Order2Cash (O2C)Team NEO
|
||||
Team Migration
|
||||
Team Fachliche Betriebsführung
|
||||
Team Technische Betriebsführung (fällt ab November 2026 weg)
|
||||
Diverse Schnittstellenpartner
|
||||
@@ -0,0 +1,19 @@
|
||||
# APN Migration - Team
|
||||
|
||||
Version: 54 | Last modified: 2025-06-04T13:41:14.131+02:00
|
||||
Source: confluence page ID 178881227
|
||||
|
||||
---
|
||||
|
||||
ProduktvisionWir stellen APN auf moderne Technologien um, damit es in Zukunft ohne die Produkte von Tibco und Software AG auskommt.
|
||||
Die Anwendung soll einfach zu benutzen, robust und sicher sein.Â
|
||||
Umgebungen APN 2.0Infrastruktur | Stage | URL |
|
||||
Entwicklung | DEV (TS1) | https://apn-dev.apn-iat.cnp-test.comp.db.de |
|
||||
Feature Abnahme | TEST (TS2, Wartung) | https://apn-wartung.apn-iat.cnp-test.comp.db.de |
|
||||
|
||||
| Common GUI | https://apn-dev.apn-iat.cnp-test.comp.db.de/apn-gui-common |
|
||||
Integration | IU | https://apn-iu.apn-iat.cnp-test.comp.db.de |
|
||||
Abnahme | AUÂ | https://apn-au.apn-abn.cnp-test.comp.db.de |
|
||||
Produktion | PUÂ | https://apn-prod.apn-prod.cnp.comp.db.de |
|
||||
RoadmaptrueRoadmap V2falseautotoptrue16425
|
||||
Sprint AblaufSprint Ablauf11069446841343
|
||||
@@ -0,0 +1,12 @@
|
||||
# APN Team Neo DoR + DoD
|
||||
|
||||
Version: 3 | Last modified: 2025-12-17T19:11:32.627+01:00
|
||||
Source: confluence page ID 528160381
|
||||
|
||||
---
|
||||
|
||||
Erster Entwurf von Marius - auf Basis diverser DoDs von O2C, anderen Teams und Vorgaben der I.IVI 12 der DB InfraGO 8.2 APN Aktuelle Orgathemen - O2C | Order2Cash - ariJa Confluence
|
||||
|
||||
DoR
|
||||
|
||||
DoD
|
||||
@@ -0,0 +1,8 @@
|
||||
# APN Wartung & Weiterentwicklung - Teams
|
||||
|
||||
Version: 13 | Last modified: 2023-12-19T15:45:58.776+01:00
|
||||
Source: confluence page ID 290164572
|
||||
|
||||
---
|
||||
|
||||
1{"body":{"text":{"color":"#465671","textAlign":"center","fontWeight":"normal","fontSize":14}},"header":{"backgroundColor":{"color":"#0149b0"},"icon":{"size":26,"name":"faBolt","color":"#fff"}},"headline":{"text":{"text":"APN Wartung & Weiterentwicklung Roadmap","color":"#fff","textAlign":"left","fontWeight":"normal","fontSize":18},"alignment":{"horizontal":"center"}},"base":{"backgroundColor":{"color":"#ffffff"},"border":{"color":"#0049b0","style":"solid","width":1,"bottom":true,"top":false,"left":true,"right":true},"borderRadius":{"radius":4},"boxShadow":{"shadows":[{"color":"rgba(0, 0, 0, 0.08)","x":0,"y":1,"blur":1,"spread":0},{"color":"rgba(0, 0, 0, 0.16)","x":0,"y":1,"blur":3,"spread":1}]}}}Roadmap APN Weiterentwicklung und Wartung.xlsx
|
||||
@@ -0,0 +1,8 @@
|
||||
# APN Wartung & Weiterentwicklung - Teams
|
||||
|
||||
Version: 13 | Last modified: 2023-12-19T15:45:58.776+01:00
|
||||
Source: confluence page ID 290164572
|
||||
|
||||
---
|
||||
|
||||
1{"body":{"text":{"color":"#465671","textAlign":"center","fontWeight":"normal","fontSize":14}},"header":{"backgroundColor":{"color":"#0149b0"},"icon":{"size":26,"name":"faBolt","color":"#fff"}},"headline":{"text":{"text":"APN Wartung & Weiterentwicklung Roadmap","color":"#fff","textAlign":"left","fontWeight":"normal","fontSize":18},"alignment":{"horizontal":"center"}},"base":{"backgroundColor":{"color":"#ffffff"},"border":{"color":"#0049b0","style":"solid","width":1,"bottom":true,"top":false,"left":true,"right":true},"borderRadius":{"radius":4},"boxShadow":{"shadows":[{"color":"rgba(0, 0, 0, 0.08)","x":0,"y":1,"blur":1,"spread":0},{"color":"rgba(0, 0, 0, 0.16)","x":0,"y":1,"blur":3,"spread":1}]}}}Roadmap APN Weiterentwicklung und Wartung.xlsx
|
||||
@@ -0,0 +1,10 @@
|
||||
# Arbeitsweisen im Team Migration
|
||||
|
||||
Version: 2 | Last modified: 2026-02-24T09:32:30.725+01:00
|
||||
Source: confluence page ID 553944594
|
||||
|
||||
---
|
||||
|
||||
Allgemeiner Ãberblick über wie arbeiten wir als Team.
|
||||
|
||||
Â
|
||||
+88
@@ -0,0 +1,88 @@
|
||||
# ITERATIVES TESTING FÃR TEAM MIGRATION
|
||||
|
||||
Version: 40 | Last modified: 2026-02-03T10:40:59.868+01:00
|
||||
Source: confluence page ID 301350453
|
||||
|
||||
---
|
||||
|
||||
TESTCOVERAGE ZIELBILD
|
||||
(Team Migration)
|
||||
|
||||
> Präsentiert in der MiKo am 21.2.2025
|
||||
|
||||
BAUSTEINE DES QA-IMPLEMENTIERUNGSKONZEPTS
|
||||
Präsentiert im PIP 37 (25.6.2025) und PIP 38 (17.9.2025)
|
||||
(in Umsetzung seit März 2024 in Team Migration)
|
||||
|
||||
AGILES TESTING
|
||||
Vorgestellt PIP 34 (11.9.2024)
|
||||
|
||||
Wir wollen APN2.0 Workflows abbilden und anhand der Workflows Test Repository aufbauen.
|
||||
|
||||
TESTKONZEPT
|
||||
Vorgestellt PIP 33 (12.6.2024, extra Folie), siehe Folien PIP 34 als Rückblick 11.9.2024
|
||||
|
||||
trueTestingfalseautotoptrue8205
|
||||
|
||||
Offene Fragen :Â
|
||||
X-Ray über 3 Teams = 3 x Jira aktuell, die Testfälle sind aber übergreifend (Vorschlag : eigenes Jira und von dort aus verknüpfen)
|
||||
Branching Konzept für die Cypress Tests
|
||||
Konzept, wann welche Tests ausgeführt werden
|
||||
|
||||
IMPELENTATION STEPS FOR END2END TESTINGÂ
|
||||
(gehört zum obigen Schaubild (Implementierungsanleitung), wurde in Einzelevents POs + SCMs vorgestellt)
|
||||
|
||||
Pipelines Testing APN MigrationÂ
|
||||
e2e Test:Â
|
||||
- BelegungsplanÂ
|
||||
VoraussetzungenÂ
|
||||
- Ein Projekt in GitLab, für das Sie CI/CD verwenden möchten.Â
|
||||
- Die Rolle Maintainer oder Owner für das Projekt.Â
|
||||
SchritteÂ
|
||||
1.Stellen Sie sicher, dass Sie über Runner verfügen, die Ihre Aufträge ausführen können. (Wenn Sie GitLab.com verwenden, können Sie diesen Schritt überspringen. GitLab.com stellt Instanz-Runner für Sie bereit.)Â
|
||||
2.Erstellen Sie eine Datei .gitlab-ci.yml im Stammverzeichnis Ihres Repositorys. In dieser Datei definieren Sie die CI/CD-Jobs.Â
|
||||
Stellen Sie sicher, dass Runners verfügbar sindÂ
|
||||
- Gehen Sie zu Einstellungen > CI/CD und erweitern Sie Runners.Â
|
||||
Wenn Sie keinen Runner habenÂ
|
||||
1.Installieren Sie GitLab Runner auf Ihrem lokalen Rechner.Â
|
||||
2.Registrieren Sie den Runner für Ihr Projekt. Wählen Sie den Shell-Executor.Â
|
||||
Erstellen Sie eine .gitlab-ci.yml-DateiÂ
|
||||
1.Wählen Sie in der linken Seitenleiste Code > Repository.Â
|
||||
2.Wählen Sie oberhalb der Dateiliste den Zweig aus, an den Sie die Datei übergeben möchten.Â
|
||||
3 Geben Sie als Dateinamen .gitlab-ci.yml ein.Â
|
||||
wählen Sie Ãnderungen festschreiben.
|
||||
Anzeigen des Status Ihrer Pipeline und AufträgeÂ
|
||||
1.Gehen Sie zu Build > Pipelines. Es sollte eine Pipeline mit drei Stufen angezeigt werden.Â
|
||||
2.Zeigen Sie eine visuelle Darstellung Ihrer Pipeline an, indem Sie die Pipeline-ID auswählen.Â
|
||||
3.Zeigen Sie Details zu einem Auftrag an, indem Sie den Auftragsnamen auswählen. Zum Beispiel: deploy-prodÂ
|
||||
Â
|
||||
|
||||
SHORTENING TEST CYCLEÂ
|
||||
Wurde im PI Anfang (März / April) 2024 umgesetzt und in diversen Einzelrunden: Janne, Andrea, Masut, mit allen Testern vorgestellt.
|
||||
|
||||
How to handle features once it reaches testing phase:
|
||||
Run test cycle for one feature repeatedly until test is sucessfull: test, fix, deliver
|
||||
One feature with all its test cycles should be finalized in one sprint
|
||||
|
||||
TEST CASES ERSTELLEN UND AUTOMATISIEREN
|
||||
TBD
|
||||
|
||||
API Testing
|
||||
|
||||
> Präsentiert im PIP XX und Präsentiert in der MiKo am 21.2.2025
|
||||
|
||||
SIT - System Integration Test (Automation Pipeline)
|
||||
> Präsentiert im PIP 38, 17.9.2025
|
||||
|
||||
Der Testautomatisierer liefert Code.
|
||||
GitLab übernimmt das Bauen, Testen und Paketieren.
|
||||
Das fertige Paket landet in der Registry.
|
||||
Von dort aus wird es automatisch in die SIT-Umgebung deployt.
|
||||
Dort läuft es in Pods und tauscht sich mit allen angebundenen Systemen aus.
|
||||
Damit haben wir einen durchgängigen, weitgehend automatisierten Prozess, der sicherstellt, dass Ãnderungen schnell, reproduzierbar und konsistent in eine Testumgebung gebracht werden.
|
||||
|
||||
Regression Testing
|
||||
> Präsentiert im PIP 37, 25.6.2025
|
||||
|
||||
Manuelles Testing in Sprints
|
||||
> Präsentiert im PIP 38, 17.9.2025
|
||||
@@ -0,0 +1,54 @@
|
||||
# Retrospektiven Team Neo
|
||||
|
||||
Version: 5 | Last modified: 2026-03-03T08:15:03.294+01:00
|
||||
Source: confluence page ID 551029606
|
||||
|
||||
---
|
||||
|
||||
Themensammlung:
|
||||
|
||||
31
|
||||
42dbae4d-d569-42c3-856b-4be6687c55a4
|
||||
incomplete
|
||||
Zusammenarbeit im Team
|
||||
|
||||
32
|
||||
ae2c4a9a-f548-40a8-b642-99f5eba0f2c2
|
||||
incomplete
|
||||
Zusammenarbeit mit Team Migration / Zusammenarbeit im ART (Richtung Ende des PI - bei I&A)
|
||||
|
||||
33
|
||||
6ccfabb7-d393-4aa1-96fe-482b575ff71c
|
||||
incomplete
|
||||
Retro auf das Retro Vorgehen
|
||||
|
||||
34
|
||||
d2ce8d56-8ee8-4ce2-8cc4-c2a32fd9b46a
|
||||
incomplete
|
||||
Retro auf weitere Meetings
|
||||
|
||||
35
|
||||
e7444ea1-d4d2-47dc-bb1a-cf586be65b2b
|
||||
complete
|
||||
Retro zum Stories schätzen: wie werden wir besser, was sind unsere Problemfelder
|
||||
|
||||
39
|
||||
8a1e56be-7a39-4b80-a660-73da7a41c09c
|
||||
complete
|
||||
Review zu Story-Umfang: sind unsere Stories zu groÃ, da sie immer nur am Ende des Sprints fertig werden
|
||||
|
||||
Wir wollen keine Stories >5 pro Sprint angehen - diese werden kleiner geschnitten.
|
||||
Wir wollen konservativer Schätzen
|
||||
Wir wollen mehr explizit die Komplexität mit betrachten / einschätzen
|
||||
|
||||
36
|
||||
1f16aace-2eeb-4633-bfc4-be321a423af0
|
||||
incomplete
|
||||
Retro zum Story Review: wie bekommen wir das âsmootherâ und pro-aktiver hin: Verweildauer âin Reviewâ weniger
|
||||
|
||||
37
|
||||
ff5bb4e0-ed39-4fdc-8662-e36d54f13a0e
|
||||
incomplete
|
||||
|
||||
Learnings aus unseren Retros (werden den Team-Regeln hinzugefügt)Wir benennen einen "Schreiber", sollten wir technisch / fachlich in unseren Meetings diskutieren, um die Erkenntnisse daraus nicht zu verlieren
|
||||
Wir validieren Story Points im Review
|
||||
@@ -0,0 +1,83 @@
|
||||
# Story Template - Team OnePiece
|
||||
|
||||
Version: 3 | Last modified: 2025-09-05T10:38:01.964+02:00
|
||||
Source: confluence page ID 485040169
|
||||
|
||||
---
|
||||
|
||||
TitelAPN (Komponente): TitelÂ
|
||||
Titel: Was gemacht wird -> ähnlich zu Git-Commits (Imperativ)
|
||||
|
||||
AkzeptanzkriterienDie Akzeptanzkriterien sollen einen bestimmten Zustand oder ein bestimmtes Verhalten der Komponente beschrieben. Im idealen Fall ist jedes einzelne AK unabhängig voneinander testbar und erfüllbar.
|
||||
Akzeptanzkriterien sollten möglichst in Gherkin-Schreibweise als testbares Szenario beschrieben sein. Die Formulierung sollte immer im positiv geschrieben sein, selbst bei einem Szenario mit negativem Ausgang. Das hat gleich mehrere Vorteile:
|
||||
Bessere Verständlichkeit
|
||||
Positive Aussagen sind für Fachbereiche und Nicht-Entwickler leichter zu lesen.
|
||||
|
||||
Beispiel:
|
||||
Negativ: Then the user is not logged in
|
||||
|
||||
Positiv: Then the user stays on the login page
|
||||
â Die zweite Variante beschreibt klarer, was tatsächlich passiert.
|
||||
|
||||
Eindeutigkeit
|
||||
Negative Formulierungen führen oft zu Interpretationsspielraum (ânicht eingeloggtâ â heiÃt das: Fehlermeldung? Zurück zur Loginseite? Einfach nichts passiert?).
|
||||
|
||||
Positive Formulierungen beschreiben ein beobachtbares Ergebnis.
|
||||
|
||||
Bessere Testautomatisierung
|
||||
Tests lassen sich einfacher prüfen, wenn ein klarer Zustand überprüft wird.
|
||||
|
||||
Positiv: Then I see an error message "Invalid credentials"
|
||||
|
||||
Negativ: Then I do not see the dashboard
|
||||
â Beim negativen Test könnte der Test "bestehen", auch wenn etwas völlig anderes angezeigt wird (z. B. eine leere Seite).
|
||||
|
||||
Weniger kognitive Belastung
|
||||
Menschen müssen bei Negationen öfter gedanklich âum die Ecke denkenâ.
|
||||
|
||||
Positiv formulierte Szenarien sind intuitiver nachzuvollziehen.
|
||||
|
||||
Eine Schablone dafür wäre:
|
||||
Scenario:Â Komponente XYZ macht etwas
|
||||
Given ein bestimmter InputÂ
|
||||
Given eine mögliche Bedingung
|
||||
When eine bestimmte Aktion oder Situation geschieht
|
||||
Then wird ein bestimmtes Verhalten beobachtet
|
||||
Then ist eine bestimmtes Ergebnis eingetreten
|
||||
|
||||
Es sollte immer mindestens ein Positiv- und ein Negativ-Beispiel vorhanden sein.
|
||||
|
||||
DetailbeschreibungZu klärende Fragen:
|
||||
Was soll in der Story geschehen?
|
||||
Welche Vorbedingung soll erfüllt sein?
|
||||
Was ist der Nutzen, den diese Story kreiert?
|
||||
|
||||
Fachliche BeschreibungFachliche Einordung der Anforderung in den Business Kontext
|
||||
Gerne auch eine grafische Ãbersicht mit Figma:
|
||||
|
||||
Technische InformationenFür die Umsetzung hilfreiche Informationen, Links etc.
|
||||
SST-Beschreibung
|
||||
|
||||
Beispiel-Datenset
|
||||
AusblickGibt es Auswirkungen auf andere Komponenten?
|
||||
|
||||
Out-of-ScopeWas soll nicht getan werden?
|
||||
|
||||
NFAVerfügbarkeit?
|
||||
Umgang mit Daten?
|
||||
Monitoring?
|
||||
Skalierbarkeit?
|
||||
ReminderDefinition of Ready:Vor Refinement von PO/BA's zu klären:* Die USER-Story ist ins Gesamtprojekt eingeordnet ("Als ... möchte ich, dass..., WEIL..."). Motivation wird erklärt und These über Nutzen der Story aufgestellt.
|
||||
* Akzeptanzkriterien sind formuliert (wünschenswert: konkretes BDD given/when/then, Example-Mapping)
|
||||
* Zusammenstellung verfügbarer fachlicher Dokumentation (verlinkt oder direkt in der Story)
|
||||
* Verfügbarkeit der Testdaten ist geklärt
|
||||
* Abhängigkeiten zu anderen Teams im Projekt oder extern sind geklärt
|
||||
* Story kann nicht fachlich sinnvoll kleiner geschnitten werden
|
||||
|
||||
Vor Schätzung einer Story von den Entwicklern zu klären* Identifikation der betroffenen (Software)-Komponenten (intern und extern)
|
||||
* Aktueller Zustand der betroffenen Software-Komponenten
|
||||
* Testbarkeit ist abgeklärt
|
||||
* Notwendige Zugangsdaten/Tools sind bekannt
|
||||
* Abhängigkeiten zu anderen Stories oder Teams
|
||||
* Verfügbare technische Dokumentation ist bekannt
|
||||
* Story kann nicht technisch sinnvoll kleiner geschnitten werden
|
||||
@@ -0,0 +1,28 @@
|
||||
# Teams-Chat / Teams-Kanäle
|
||||
|
||||
Version: 3 | Last modified: 2024-02-15T11:36:02.611+01:00
|
||||
Source: confluence page ID 314182207
|
||||
|
||||
---
|
||||
|
||||
Wofür benötigen wir einen eigenen Kanal?Für Announcements (keine Diskussion)Wer reported: PM, PO (SCM), SysArch
|
||||
Wer hört zu: Alle Teams
|
||||
Wer reagiert: Keine Interaktion vorgesehen über diesen Channel. Bei Diskussionsbedarf PM
|
||||
|
||||
Für Prod-Issues/Incidents:Wer reported: FB, PO, PM
|
||||
Wer hört zu: PO's, SCM!? Fachbereich, Value-Ops'ler
|
||||
Wer reagiert: PO's deligieren/verteilen und informieren Issuebezogen über den Stand
|
||||
Welche Inhalte werden gepostet;Fehler in Produktion
|
||||
Systemausfälle
|
||||
Schwerlast
|
||||
|
||||
Staging Issues:Wer reported: Tester, Fachbereich, Devs (app, Infrastruktur)
|
||||
Wer hört zu: TO BE DISCUSSED
|
||||
Wer reagiert: jeweils ein Verantwortlicher(PO?) antwortet auf die initiale Info-Messsage, deligiert und informiert über Stand
|
||||
|
||||
APN All Stars:Wer
|
||||
.
|
||||
.
|
||||
Welche Inhalte:
|
||||
|
||||
Monitoring Board Serviceübersicht (eigene App)Weiteren Ausbau gestalten und planen
|
||||
+106
@@ -0,0 +1,106 @@
|
||||
# <deprecated?->ask Team Neo> APN Arch: Eigenbedarf-Backend 2.0
|
||||
|
||||
Version: 68 | Last modified: 2025-10-17T15:13:03.693+02:00
|
||||
Source: confluence page ID 361137191
|
||||
|
||||
---
|
||||
|
||||
Diese Seite Beschreibt das Migration des Services eigenbedarf-backend ins APN 2.0
|
||||
Die Empfehlung ist das Migration in zwei Iterationen durchzuführen.
|
||||
Iteration 1: enthaltet die für die Migration unbedingt notwendige Schritte: Umzug ins Aurora DB im Rahmen eines neues Services eigenbedarf-backend-2.0 und das dazugehörige Frontend Umleitung im Rahmen des eigenbedarf-frontend 2.0
|
||||
Iteration 2: kann nur später durchgeführt werden, wenn die im jeweiligen Iteration genannten Voraussetzungen erfüllt sind. Das beinhaltet die Ausbau der Datenquelle VOV und die Umsetzung als neues Feature, die Anlage der Anmeldungen/Verträgen
|
||||
Das Migration soll erstmal nur für 1 Stage (ts1/apn_dev) durchgeführt werden, und nach erfolgreichen Test für die andere Umgebungen.
|
||||
Iteration 1
|
||||
1. DB Umzug: Oracle -> AuroraDie EB-Tabellen sollen aus Oracle ins Aurora DB inklusive Inhalt umgezogen werden.
|
||||
Notwendige Tools/Clients einrichten: Anbindung zum Aurora. Die notwendige Schritte befinden sich an der folgende Seite: Howto Einrichtung APN Migration-Services mit Aurora DB - O2C | Order2Cash - ariJa Confluence (deutschebahn.com) (Story-1: das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-7161)
|
||||
Neues Schema anlegen für Eigenbedarf - neue Schema für jede Services (Story-2: das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-7162)
|
||||
2 neue technische Benutzern anlegen: (Story-2)
|
||||
Für die Regelbetrieb analog zu Oracle, sowie apn_iu_betrieb
|
||||
Für Schema Migration mit erweiterte Rechte, sowie apn_iu_owner
|
||||
|
||||
Neue Benutzern im Kubernetes Secrets hinterlegen. Das erfolgt sich im Rahmen des Secret Managements - Setup Secret für jede notwendige Benutzern, wie folgt: (Story-2)
|
||||
1. Ein Secret ins lokale Datei "activemqconnection--apn-wartung" herunterladen: kubectl get secret activemqconnection--apn-dev -o yaml > activemqconnection--apn-wartung
|
||||
  Beispiel secret yaml files: .\OpenLens\beispiel_secret_yaml_files\activemqconnection--apn-wartung, .\OpenLens\beispiel_secret_yaml_files\auroraconnection--apn-wartungÂ
|
||||
2. Editieren heruntergeladene Date "activemqconnection--apn-wartung"
|
||||
3. Neues Secret hochladen: kubectl apply -f activemqconnection--apn-wartung
|
||||
  Rückmeldung: secret/activemqconnection--apn-wartung created
|
||||
4. Füge das entsprechende secret-claim (zum Beispiel: activemqconnection) zur Datei
|
||||
  https://git.tech.rz.db.de/cnp/apn/apn-ops/-/blob/develop/apn-iat/cnp-api-iat-v4/secret-claims.yml?ref_type=heads
|
||||
5. Merge ins develop.Â
|
||||
  secret-claim holt das Secret und schreibt ins AWS Secret Manager (AWS-SM) und fügt Berechtigungen hinzu.
|
||||
6. secret-claim wird via ArgoCD geladen.
|
||||
  Prüfe die neu hochgeladene secret-claim in ArgoCD (zum Beispiel: https://argocd.cnp.comp.db.de/applications/argocd/apn-iat-v4-claims?view=tree&node=cnp.comp.db.de%2FSecret%2Fapn-iat%2Fauroraconnection--apn-wartung%2F0&resource=)
|
||||
  Die Name des secret-claim wird erstellt aus die folgende Attributewerte:
|
||||
  apiVersion: cnp.comp.db.de/v1alpha1
|
||||
  kind: Secret
|
||||
7. Hole die secret claims: kubectl get secret.cnp.comp.db.de
|
||||
8. Es muss danach der secret-provider angelegt werden, der auf das AWS-SM secret verweist. (den hash im Namen kann man aus der secret-claim-Ressource ablesen, via kubectl oder OpenLens):
|
||||
  Hole das secret claim für Aurora connection: kubectl get secret.cnp.comp.db.de auroraconnection--apn-wartungÂ
|
||||
9. Wenn der Secret-Provider steht und richtig konfiguriert ist, sollte man das Service neu deployen können. Dieser packt dann das secret via secret-provider automatisch aus und mounted es in den zugehörigen Applikations-Pod
|
||||
DDL migration via Liquibase (Story-3: das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-7163)
|
||||
Liquibase Module ins EB-Backend integrieren
|
||||
Liquibase DDL ins maven Module integrieren
|
||||
|
||||
Hinweis: Dieser Ansatz ist schon beim Migration-Services Umgesetzt, wodurch die relevante Logik dementsprechend übernommen werden soll.
|
||||
Laden der Daten - Das Ladeprozess soll sich mit Event-getriebene Datensynchronisation, basierend auf das Outbox Pattern (Pattern: Transactional outbox (microservices.io)) erfolgen.
|
||||
Team Migration hat schon ähnliche Logik bzgl. der Anmeldungen Implementiert. (Story-4: das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-7164, Story-5: das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-7165)
|
||||
Da bei allen Eigenbedarf-Ãnderungen die Tabelle EIGENBEDARF_REVINFO gefüllt wird, für die Oracle Tabelle EIGENBEDARF_REVINFO einen Trigger hinzufügen, der die betroffene (neue/geänderte/gelöschte) Rekord in einer sogenannte Outbox Tabelle schreibt
|
||||
Beispiel Trigger, der die Anmeldenummer ins Outbox Tabelle EVENT schreibt: DB/db_skripte/release320700/APN_EDIT_TRIGGER_SYNC_ANMELDUNG.sql · master · apn-eip / src / DatenbankDevelopment · GitLab (Story-4)
|
||||
Initial Laden Implementieren. Dazu gibt es 2 Möglichkeiten: (Story-4)Bevorzugt: Logik für das initiale Laden zu Implementieren, die die schon existierende Rekorde zur Outbox Tabelle hinzufügt. Diese Logik soll via eine Rest-Endpunkt zur Verfügung gestellt werden.
|
||||
Beispiel: src/test/java/com/dbnetz/apn/event/service/messaging/initialload · develop · apn / common / spring / modules / event-classic-backend · GitLab
|
||||
|
||||
Zusätzliche Spalte (zum Beispiel mit der Name "status" und mit dem Wert "updated") zur Tabelle EIGENBEDARF hinzufügen, um das Trigger für alle schon existierende Rekorde zu initiieren. Daher wird der Trigger für alle schon existierende Zeilen gefeuert. Andere Tabelle im Bezug eigenbedarf muss nicht geändert werden, da die alle eine Verknüpfung zum Tabelle EIGENBEDARF haben.
|
||||
|
||||
Trigger schreibt die Daten in der Outbox Tabelle (Story-4)
|
||||
Das schon existierende Eventing Service event-classic-backend zieht das ganze eigenbedarf Struktur zusammen (dazu muss das Service erweitert werden oder alternativ neue Service erstellt werden) und fügt zu einem Queue hinzu. Klären mit Team Mig. ob die verarbeitete Zeilen in der EVENT Tabelle gelöscht werden können. (Story-5)
|
||||
neue Version von eigenbedarf-backend 2.0 mit Aurora DB wird mit Event Topic Abarbeitung erweitert und arbeitet die Queue Elemente ab (Story-5)
|
||||
|
||||
Das Ladeprozess muss nur in die hier beschriebene Richtung implementiert werden: Oracle DB â Aurora DB
|
||||
Frontend auf eigenbedarf-backend 2.0 umleiten (siehe nächste Punkt 2) (Story-6: das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-7166, Analyse Story-7: das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-7167 â Story-8)
|
||||
Prüfen ob und wann eigenbedarf-backend 1.0 abgebaut werden kann (Analyse Story-7 â Story-8)
|
||||
2. Anpassung der Suchen im Frontend auf die Aurora Datenbankeigenbedarf-frontend-2.0 mit neue Endpunkt Aufrufe Richtung eigenbedarf-backend 2.0 anzulegen (Story-6)
|
||||
eigenbedarf-frontend-2.0 testen und Fehlerbehebung, während damit parallel eigenbedarf-frontend weiterhin lauft. Es ist möglich zwischen die 2 Frontends umzuschalten (Story-6)
|
||||
Prüfen ob und wann eigenbedarf-frontend 1.0 abgebaut werden kann (Analyse Story-7 â Story-8)
|
||||
Iteration 21. Ausbau Zugriff zum externen Datenquellen bzgl. VorsystemAnhängigkeit: das Migration des Services, die die notwendige Daten (Nutzungsobjekte, Steurende Attribute, usw.) liefern (VOV - vorsystem-persistence, usw.).
|
||||
Auf Grund dessen, in der Erste Iteration des Migration, diese Logik kann unverändert so bleiben wie es aktuell ist, erweitert mit der Aurora Zugriff. Daher das Service eigenbedarf-backend 2.0 wird zuerst auf drei Datenquellen zugreifen: VOV (SteuerndeAttributen), Oracle, CNP (Aurora)
|
||||
Klären, ob die Funktionalität 1-1 so wie es aktuell ist, übernommen werden kann?
|
||||
IST StandDas aktuelle eigenbedarf-backend holt direkt die notwendige Daten (Nutzungsobjekte, Steurende Attribute, usw.) aus zwei Oracle Schemata: Oracle VOV (Steuerndeattribute) und Oracle APN.
|
||||
SOLL StandIm Gegensatz dazu, in APN 2.0 es wird pro Domäne ein Service laufen, und die notwendige externen Daten sollen anstatt Direkt DB Zugriff bei der Verwendung das Outbox Pattern abgeholt sein.
|
||||
VorgehenEs sollen die Services migriert werden, die Daten für das Service eigenbedarf-backend 2.0 produzieren. â Abhängigkeit zum Team Mig.
|
||||
Als alternative Lösung die notwendige Services können selber migriert werden.
|
||||
Wenn das Migration des betroffenen Services sowie VOV - vorsystem-persistence durch sind, dann wird es möglich sein bei der eigenbedarf-backend 2.0 die Daten zu holen.
|
||||
Für die Umsetzung diese zwei Punkte, siehe nächste Punkt "Allgemeine Konzept für Outbox Pattern".
|
||||
Allgemeine Konzept für Outbox PatternNeben eigenbedarf, es gibt andere Services, die externen Daten von anderen Services benötigen. Im System existieren also mehrere Services in der Rollen Producer und Consumer. Ziel ist es, die Producer und Empfänger Services zu entkoppeln. Daher in einem Separatem Konzept (Konzept Story-11) eine Systemübergreifende Lösung bzgl. der Verwendung des Outbox Patterns notwendig ist. In diesem Konzept die Umsetzung der folgende Funktionalität soll näher Beschrieben werden:
|
||||
Die Services, die Daten für andere Services zur Verfügung stellen, schicken bei allen Ãnderungen via event-service (z.B. event-classic-backend) die Steuernde Attribute, Nutzungsobjekte in einem Queue/Topic in ActiveMQ. Klären (ggf. ADR erstellen): kann dafür event-classic-backend verwendet werden, oder sollte mehrere event-service existieren?
|
||||
Die Services, die Daten von andere Services benötigen, subscriben auf die Topics, woher die benötigte daten kommen, und diese Daten dann verarbeiten.
|
||||
Das Service eigenbedarf-backend 2.0 soll auch dieses Vorgehen realisieren, und anschlieÃend die relevante Daten in der Aurora DB ablegen (Story 12).
|
||||
2. Anlegen von Anmeldungen/Verträgen aus APN 2.0 ins Altsystem/Tibco (in Abstimmung mit Migration)Abhängigkeit (nur Punkt 3): eigenes Konzept wurde erstellt, wie die TIBCO Logik bzgl. des Anlegens der Anmeldungen/Verträgen in APN 2.0 umgesetzt werden kann.
|
||||
TIBCO verfügt schon die Logik bzw. SSt., die Ermöglichen Anmeldungen/Verträgen anzulegen. Diese SSt. ist bei MWS verwendet. MWS verfügt aber keine SSt., via es - bei der eigenbedarf-frontend - möglich ist, diese TIBCO Funktionalität zu nutzen, und Anmeldungen/Verträgen anzulegen. Seit die neuere MWS Versionen es ist auch nicht möglich solche SSt. zu definieren.
|
||||
Daher hier es um eine neue Feature handelt.
|
||||
VorgehenGenerell gilt, das neue APN 2.0 und das Altsystem zu entkoppeln, daher es Event basierte Ansatz mit der Benutzung Outbox Pattern verwendet werden soll:
|
||||
Bzgl. des Anlegens von Anmeldungen/Verträgen, das neue eigenbedarf-frontend 2.0 ruft das Service eigenbedarf-backend 2.0 auf, das dann diesbezüglich ein Event in einem Queue ablegt. MWS abarbeitet die Event und ruft die TIBCO SSt. auf (Story 13)
|
||||
Im Altsystem (TIBCO) die neu angelegte Anmeldungen/Verträgen werden ins Event Queue geworfen. APN 2.0 liest anschlieÃend die Elemente aus und legt die Anmeldungen/Verträgen in der Aurora DB an. (Story 14)
|
||||
Umsetzung des Anlegens der Anmeldungen/Verträgen (die aktuell nur in TIBCO vorhanden ist) direkt in APN 2.0 â eigenes Konzept ist notwendig. (Konzept Story 15)
|
||||
|
||||
truekonzept-eigenbedarf-backend-2.0falseautotoptrue14918
|
||||
|
||||
Das APN - Datenmodell für Eigenbedarfe:
|
||||
|
||||
Das Fachdatenmodell
|
||||
 Versionierung/Bearbeitungshistorie (HibernateEnvers):
|
||||
Datenbanktabellen inklusive Versionierung/Bearbeitungshistorie (HibernateEnvers):
|
||||
|
||||
Hilfreiche Ressourcen für den KontextSteuernde Attribute publizieren:Screenshots und Beispiele kann man sehen anhand desÂ
|
||||
|
||||
Datenbank-Trigger an einem Beispiel:
|
||||
Event-Tables:
|
||||
Zur Erklärung:
|
||||
Die Spalte Eventtyp ist ein Enumeration (siehe Javacode oder Typ-Tabelle).
|
||||
Die Spalte EventValue ist typspezifisch. Allgemein wird hier die Referenz auf das Root-Aggregate des zu übermittelnden Datensatzes referenziert.Für Anmeldungen ist das die Anmeldenummer
|
||||
Für Eigenbedarfe müsste das hier entsprechend die Eigenbedarf_ID sein.
|
||||
|
||||
Der Eventservice nimmt den Eventvalue, um daraus den Payload der einzustellenden Nachricht zu berechnen (und als JSON zu serialisieren).
|
||||
|
||||
Bestehende Topics/Queues/CompositeTopics:https://git.tech.rz.db.de/cnp/cnp-managed/apn-iat/-/blob/master/cnp-api/activemq/config/broker-config.xml?ref_type=heads
|
||||
Message Producing-Example:https://git.tech.rz.db.de/apn/common/spring/modules/event-classic-backend/-/blob/develop/src/main/java/com/dbnetz/apn/event/service/messaging/ApnAnmeldungEventPollingService.java?ref_type=heads#L54-58
|
||||
Migrations-Fahrplan und Kontext zum zeitlich geplanten Ablauf einer Migrationsstrategie:
|
||||
+116
@@ -0,0 +1,116 @@
|
||||
# Ãbergabeprotokoll â Testautomatisierung & Qualitätssicherung im APN Team NEO
|
||||
|
||||
Version: 8 | Last modified: 2026-01-14T11:49:29.717+01:00
|
||||
Source: confluence page ID 533416420
|
||||
|
||||
---
|
||||
|
||||
Dieses Dokument beschreibt die durchgeführten Test- und Automatisierungsaktivitäten im Rahmen der Projektübergabe.
|
||||
Aktuell werden zwei Frontends parallel durch das Testteam betrieben und getestet (alte Welt APN-Classic auf der EIP-Plattform / neue Welt APN 2.0).Aufgaben im Bereich EIP / APN-Classic
|
||||
Selenium-Testfälle AllgemeinDas Projekt wurde ursprünglich von einer externen Automatisierungsexpertin aufgebaut. Die Testfälle wurden in Java mit Selenium und Cucumber implementiert.
|
||||
Repository URL: https://git.tech.rz.db.de/apn/quality-assurance/apntestsuite
|
||||
|
||||
Die Tests werden in 8 Threads parallel ausgeführt. Laufzeit ± 1 Stunde.
|
||||
|
||||
Secret-Handling (CNP):Die Secrets des Automatisierungsprojekts werden zur Job-Laufzeit aus dem AWS Secretmanager geladen. Der Zugriff erfolgt je nach Job und Umgebung (Stage).
|
||||
TS1: /run/secrets/testautomation--apn-dev/gitlabrunner--testautomation--apn-dev
|
||||
TS2: /run/secrets/testautomation--apn-wartung/gitlabrunner--testautomation--apn-wartung
|
||||
IU: /run/secrets/testautomation--apn-iu/gitlabrunner--testautomation--apn-iu
|
||||
AU: /run/secrets/testautomation--apn-abn/gitlabrunner--testautomation--apn-abn
|
||||
|
||||
Testfallmanagement & Reporting (Jira / Xray) Die Testfälle werden in Jira (Xray) gemanaged.
|
||||
Insgesamt sind ca. 150 Testfälle in Jira angelegt
|
||||
|
||||
Das Xray-Reporting erfolgt automatisiert über die CI/CD-Pipeline
|
||||
|
||||
Nach jeder Ausführung wird der Report im folgenden Test-Plan-Ticket hochgeladen: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-7935
|
||||
|
||||
Fehlgeschlagene Testfälle werden lokal auf dem Rechner nachgetestet. Bei erfolgreichem Retest wird der Status im Test-Plan auf PASS gesetzt.
|
||||
Für den Upload der Reports nach Jira wird ein persönlicher API-Token verwendet, der 365 Tage gültig ist. Nach Ablauf muss ein neuer Token erstellt und in CNP deployt werden. Dazu bitte im Team fragen.
|
||||
Zusätzlich steht der Cucumber-Report auch in den Job-Artifacts der Pipeline zur Verfügung.
|
||||
CI/CD-Konfiguration & TestjobsDie gitlab-ci.yml ist so aufgebaut, dass pro Umgebung ein eigener Stage definiert ist. Ist abgelegt unter: Pipelinetemplates Projekt
|
||||
Innerhalb jedes Stages sind die jeweiligen Ausführungsjobs hinterlegt. Ausnahme: TS1, da dort überwiegend vollständige Regressionstests ausgeführt werden.
|
||||
Verfügbare Jobs pro Stage:Smoke Tests
|
||||
Test der Grundfunktionalitäten
|
||||
Geplant über Pipeline Schedule täglich um 07:45 Uhr auf allen Umgebungen
|
||||
|
||||
Security Tests
|
||||
Aufruf bestimmter webMethods-Seiten mit Anmeldung
|
||||
Prüfung, ob angemeldete Benutzer Zugriff haben
|
||||
|
||||
Durchstich Tests
|
||||
Ausführung der Durchstich-Testfälle
|
||||
Ebenfalls täglich um 07:45 Uhr auf allen Umgebungen
|
||||
|
||||
Security Tests (Anonym)
|
||||
Aufruf bestimmter webMethods-Seiten ohne Anmeldung
|
||||
Prüfung, dass nicht angemeldete Benutzer keinen Zugriff haben
|
||||
|
||||
Full Regression Tests
|
||||
Werden nach jeder erfolgreichen Lieferung ausgeführt
|
||||
(z. B. nach Deployment auf AU)
|
||||
|
||||
Hotfix Tests
|
||||
Nach jedem Hotfix werden folgende Jobs ausgeführt:
|
||||
Security
|
||||
|
||||
Security Anonymous
|
||||
|
||||
Smoke Tests
|
||||
|
||||
Hotfix Tests
|
||||
|
||||
Selektiv
|
||||
Ermöglicht die gezielte Ausführung einzelner Testfälle, die entsprechend getaggt sind
|
||||
|
||||
Manuelle Tests & Bug-RetestsDurchführung manueller Tests bei:
|
||||
Bugfixes
|
||||
|
||||
neuen Feature-Implementierungen
|
||||
|
||||
Die Tests werden als Unteraufgabe mit dem Titel âTestâ im Jira-Board zugewiesen
|
||||
|
||||
Bei Fragen oder Auffälligkeiten erfolgt eine direkte Abstimmung mit dem jeweiligen Entwickler
|
||||
|
||||
Aufgaben im Bereich APN 2.0Testautomation Dashboard: https://arija.jaas.service.deutschebahn.com/secure/Dashboard.jspa?selectPageId=37600Testautomatisierung & ReportingIntegration von Cypress inklusive Xray-Reporting
|
||||
|
||||
Cypress-Projekt-Repository:
|
||||
https://git.tech.rz.db.de/apn/quality-assurance/apn-cypress
|
||||
|
||||
Verwendung von Pipeline-Modulen des PipelineTeams der MoQ-AP
|
||||
|
||||
Einbindung und Nutzung von AWS Secret Keys
|
||||
|
||||
Xray-Reporting:
|
||||
Bei jeder Ausführung wird das Ergebnis in den entsprechenden Jira Test-Plan hochgeladen:  das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-8281
|
||||
|
||||
Wichtig: Der Upload der Testergebnisse nach Jira (Xray) erfolgt derzeit nicht automatisch, sondern wird über einen manuell auszulösenden CI/CD-Job (rule: manual) gesteuert.
|
||||
Für eine automatische Ausführung muss diese Rule entfernt werden.
|
||||
|
||||
Ressourcen für die Testfall ErstellungAnlage der Testfällen in Jira auf Basis von:
|
||||
Definierter Workflows: https://arija-confluence.jaas.service.deutschebahn.com/spaces/BES/pages/464844624/Workflows+Logistkgleise+und+GLAD
|
||||
|
||||
Bestehender Diagramme und Konzepte:Â
|
||||
|
||||
Figma:Â https://www.figma.com/file/qq3zIZ7ZCvGGw0lOZ3n8DV/apn
|
||||
4-Augen-Prinzip
|
||||
Review der angelegten Testfälle gemeinsam mit TestManager und BusinessAnalyst
|
||||
|
||||
Ablage der Testfälle in JiraGLAD: https://arija.jaas.service.deutschebahn.com/secure/XrayTestRepositoryAction!default.jspa?entityKey=O2CAPN&path=APN%202.0%2FGLAD
|
||||
|
||||
Logistikgleise: https://arija.jaas.service.deutschebahn.com/secure/XrayTestRepositoryAction!default.jspa?entityKey=O2CAPN&path=APN%202.0%2FLogistikgleise
|
||||
|
||||
Manuelle Tests & Bug-RetestsDurchführung manueller Tests bei:
|
||||
Bugfixes
|
||||
|
||||
neuen Feature-Implementierungen
|
||||
|
||||
Zuweisung über Jira-Unteraufgabe mit dem Titel âTestâ
|
||||
|
||||
Abstimmung bei Fragen direkt mit dem jeweiligen Feature-Entwickler
|
||||
|
||||
Hinweis für die ÃbergabeSelenium wird ausschlieÃlich für die Regression der alten Welt genutzt
|
||||
|
||||
Cypress ist das strategische Zielsystem für die neue Welt (APN 2.0)
|
||||
|
||||
Weitere Erweiterungen der Testabdeckung sollten ausschlieÃlich in Cypress erfolgen für die neue Welt, da EIP zum 12/2026 abgeschaltet wird.Â
|
||||
Reference in New Issue
Block a user