Files

T

ankn a5f8fb49ab 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.

2026-06-30 20:39:52 +02:00

76 KiB

Raw Blame History

Architekturrunde PathOS

Confluence Page ID: 116555799 Version: 743 Pfad: /pathOS/KommunikationskanÃ¤le, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/Architekturrunde PathOS Labels:

Dies ist der Regeltermin um Ã¼ber anstehende Architekturentscheidungen zu sprechen und diese voranzutreiben. Die Ablage der Entscheidungen erfolgt weiterhin in Gitlab. Eine Auflistung hier soll primÃ¤r der Vorbereitung der Termine dienen, insbesondere um sicherzustellen, dass relevante Entscheider dabei sind. Die aktuelle Version der Architekturbeschreibung findet man hier. Ãltere Termine sind imÂ zu finden.

ADRs in Arbeit

| | Nr | Titel | Branch | MR | | ADR-72 | Technische Anbindung von Click&Ride an PathOS | |

| | ADR-74 | Technische Anbindung von TrassenPortal an PathOS | |

| | ADR-75 | Maximierung VerfÃ¼gbarkeit der genutzten Container-Registries | | https://git.tech.rz.db.de/bestellsystem1/docs/runbook/-/merge_requests/553

Agenda-Backlog

Agenda 10.4.2026

Yellow-Lane soll perspektivisch abgeschaltet werden
Beginn mit ITU Anfang Mai
weitere Informationen folgen
Staging-Pipelines: Momentan laufen die Staging Pipelines auch fÃ¼r HF-Pipelines, dass fÃ¼hrt dazu, dass HF-Versionen auf Base, IEU, SIT und E2E eingetragen werden, obwohl sie ggf. nicht mehr mit der jetzigen Release-Version kompatibel sind und Ã¤ltere FunktionalitÃ¤ten beinhalten.
keine automatische Ãbernahme von Hotfiix-Versionen in Base-, IEU- und SITx-UmgebungenÂ
Steuerungsparameter an Pipeline, um das Verhalten zu Ã¼berschreiben
Ticket bei SUPB anlegen
API-Projekt data-model: Â
Das Projekt hat die falsche groupId:Â https://git.tech.rz.db.de/bestellsystem1/apis/data-model/-/blob/master/pom.xml?ref_type=heads#L12
wurde bereits korrigiert â muss in den Apps berÃ¼cksichtigt werden
Zyklische AbhÃ¤ngigkeit:Â
https://git.tech.rz.db.de/bestellsystem1/apis/api-parent-pom/-/blob/main/pom.xml?ref_type=heads#L473
https://git.tech.rz.db.de/bestellsystem1/apis/data-model/-/blob/master/pom.xml?ref_type=heads#L8
data-model-AbhÃ¤ngigkeit in api-parent-pom soll entfernt werden

Agenda 6.3.2026

Vorstellung Entwurf ADR-72 Technische Anbindung von Click&Ride und TrassenPortal an PathOS
Weiterentwicklung Systemtest
Schritt 1: Umstellung auf Plain-JUnit (das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CDEVOPS-794)
Schritt 2: TestDataContext entzerren (das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CDEVOPS-795)
Bing/Team-Zero: Kafka-Topic Option "retentionMS" vereinheitlichen?
Aktuell in Prod: Topic Tbv-Absicherung mit 365 Tage und alle andere Topics mit 7 Tage.Â
Normale Topics: Standard 7 Tage, bei fachlich abweichender Anforderung wie z.B. TBV oder Stationsportal auch hÃ¶here Werte
Error-/DLTs: Standard 30 Tage
Einen einheitlichen Wert fÃ¼r die ABN/SAT-Umgebungen zu finden?
Information:Â TBV ist eine sensible Schnittstelle. Ãnderungen an der Konfiguration bitte nicht ohne RÃ¼cksprache durchfÃ¼hren!
Information:Â Mit TBV ist eine abweichende Retention vereinbart, deshalb muss die Konfiguration so bestehen bleiben.
David/Team-Subp: Sub-Artefakte wie libraries oder apis automatisiert verÃ¶ffentlichen
Aktuell wurde von Subp Seite eine Umstellung der Pipeline auf "release by tagging only" vorbereitet
Das wurde der CI/CD Runde kritisiert, weil damit zusÃ¤tzlich nach allen Renovate MRs noch zusÃ¤tzlich zum Zeitpunkt X manuell eine Version getaggt werden muss und nachgelagert dann alle Apps auf diese neue Version updaten muss.Â
Man mÃ¶chte das weiterhin der stable Branch ins release-Artifactory verÃ¶ffentlicht wird.Â
Fragen:
will man das prinzipiell von der Architekturrunde?
wie werden die Version dann gebildet? aktuell ist bspw. bei apis der stable Branch ein semver Pre-Release "next"
Diskussionsergebnis:
Libraries: HÃ¤ndisches Tagging bei manuellen Ãnderungen, Automatismus bei Renovate-Bot-Anpassungen
APIs: HÃ¤ndisches Tagging grundsÃ¤tzlich sinnvoll zwecks Nachvollziehbarkeit bei Bestellsystem-Releases.

Agenda 6.2.2026

Aktuelle Situation in den Pipelines: wurde durch die SIT2 die Situation aus Sicht der Teams besser?
Hat geholfen â Pipelines sind nicht mehr blockiert, wenn manuelle Tests auf der SIT stattfinden
SAT 3 fÃ¼r LuPs und DRT (temporÃ¤r)
Integration der AV in die Portal-Middleware (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-7720150f306eO2CBS-647)
Refactoring und Code-Cleanup in Portal-Middleware vorab
SAB-Team benÃ¶tigt ggf. die AV
HÃ¶here Priorisierung von Themen zur Verbesserung der QualitÃ¤tssicherung von PathOS
Henrik/OpsSquad: Metrics und Alerts
JVM-Metrics notwendig, um den tatsÃ¤chlichen Speicherverbrauch auswerten zu kÃ¶nnen
Jonas/CIB: Umstellung aufÂ https://git.tech.rz.db.de/devex/hardenedimages
Vorschlag Jonas: Verwendung ab Java 25Â
Enabler fÃ¼r Umstellung erstellen â Â
Vorschlag Christian P.: Parallele Pipeline zum Testen der nÃ¤chsten Major-Version
Auf Applikations-Ebene in MR-Pipelines
Auf Deployment-Ebene wÃ¤re es nochmal zu prÃ¼fen
Testgrenzen klarer fassen â , Â
API-Informationen in Release-/Hotfix-Tickets mit aufnehmen (Sicherstellung der AbwÃ¤rtskompatibilitÃ¤t)
eigener Abschnitt fÃ¼r APIs

Agenda 1.12.2025

Henning/CIB: Spring Boot 4 Upgrade (Spring Boot 3 OSS EOL 2026-06)
Thema fÃ¼r PI 40 â Enabler âÂ 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-7720150f306eO2CBS-1001
Separater Enabler fÃ¼r JUnit 5 â JUnit 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-7720150f306eO2CBS-1002
Saurav/CIB: Gibt es ein definiertes Konzept oder einen Plan fÃ¼r die Migration auf Camunda 8.8 oder 8.x? In diese Versionen sind zahlreiche Breaking Changes enthalten, die mÃ¶glicherweise zu Datenverlust in der Produktion fÃ¼hren kÃ¶nnten. https://docs.camunda.io/docs/apis-tools/migration-manuals/
Analyse der notwendigen Migrationsschritte hinsichtlich Aufwand und Risiko im Bestellsystem â Team CIB, Â
Saurav/CIB: Die Blockierungen der SIT Runners fÃ¼hren dazu, dass die gesamte Pipeline stillsteht. Gibt es einen Plan, dieses Problem vor der Produktivsetzung zu verbessern?
Automatisierte SITs nur noch in der Tag-Pipeline; nicht mehr in der Master-Pipeline â Â
Frank/Zero: Logging von Messages (Datenschutz)
Personenbezogene Daten in Logs sind zu maskieren

Agenda 17.11.2025

STeam: PostMortem Rotation Artifactory Token
Tokens sollten Ã¼ber Releaseprozess rotiert werden, was aber aus nicht ganz geklÃ¤rten GrÃ¼nden nicht funktioniert hat. Frage: Was ist konkret schief gegangen und wie kÃ¶nnen wir sicherstellen, dass es beim nÃ¤chsten Mal klappt?
Secrets wurden in umgebungs-konfiguration nicht vollstÃ¤ndig ersetzt
TODO: Secrets aufrÃ¤umen, auf fehlerhafte Secret-Namen prÃ¼fen Â
TODO: Struktur in bestellsystem-ops fÃ¼r alle Umgebungen/Cluster usw. vereinheitlichen Â
Manager-Rolle in Artifactory benÃ¶tigt, um neue Tokens zu generieren (â Berechtigungen prÃ¼fen )
Dead Letter Topics:
Einheitliches Namensschema: --error
Dokumentation Â

Agenda 17.10.2025

Agenda-Backlog

Martin / STeam: ADR fÃ¼r ECR-Nutzung ist in Writing
Entscheidung â ECR nur als Backup Â Â Â Â Â Â Â Â Â Â Â Â Â â ECR nur fÃ¼r Prod und Tests in Preprod (alle 3-4 Monate)
Martin/STeam,Â was genau soll eigentlich der Systemzustands-Check mit dem Developer Portal machen?
in der Praxis sehe ich das nur als Check darauf ob Secret-Leaks erkannt werden.
alles weitere erlebe ich persÃ¶nlich nur als sinnloses Abtippen von bekannt false positive Zahlen aus einem Dashboard in einen Teams-Kanal. â nur Secrets in DXC Portal prÃ¼fen und Security Findings nur aus Trivy/Aqua betrachten â Henning macht Doku Â
Einheitliches Hotfix-Vorgehen
Vorlage aus CIB besprechen
Ãnderungen am Vorgehen abstimmen und beschlieÃen siehe: https://git.tech.rz.db.de/bestellsystem1/docs/runbook/-/merge_requests/431
CDaaS-Update via Renovate automatisieren? Yay or nay? Soll heissen: Wie kÃ¶nnen wir hier autoamtisieren, ohne gegen den Releaseprozess zu arbeiten?
Wenn nein, gibt es Teilaufgaben eines Updates, die sich automatisieren lassen, ohne die Releaseprozess zu "gefÃ¤hrden"? â update in hÃ¶heren Versionen via Release Prozess â ja updates via Renovate
Zusammenlegung der APIs in ein Multi-Modul-Maven-Projekt â erstmal nicht umsetzen

Agenda 19.09.2025

Hotfix-Releases: Problematisch, dass durch regulÃ¤re Releases die SIT gesperrt ist
AbwÃ¤gung der PrioritÃ¤ten von Hotfix + Release
Um Sperrzeiten herum arbeiten
SITs automatisieren
Java 25: EOL Java 21 Amazon Corretto ist 31.10.2030 bzw. Eclipse Temurin ist 31.12.2029 â Umstellung auf Java 25 nach Go-Live
Martin / STeam: brauchen wir den infra/infrastruktur-kafka-container noch?
das ist ein Bitnami-Image mit Security-Findings ohne Updates, und wir haben aktuell keinen 1:1-Ersatz dafÃ¼r
wir schlagen vor das Image und Repo zu lÃ¶schen
AFAIK gab es drei Use-Cases:
Helm kafka-setup-Jobs => wurde durch neues Tool ersetzt
Topics Debugging => wurde durch kafbat/kafka-ui ersetzt
Tool-Image fÃ¼r Notfall-Debugging und Runbook-Scripte => wurde vermutlich nicht vorbereitet, ist im Runbook nicht dokumentiert => noch relevant?
Entscheidung: Wird nicht mehr benÃ¶tigt; kann archiviert werden
Auch aus versions.yaml entfernen
Martin / STeam: ADR fÃ¼r ECR-Nutzung ist in Writing
Gerne mit- und gegenlesen. Wir haben aktuell grob drei offene Fragen vor einem Einbau von Amazon ECR als ErgÃ¤nzung zu Artifactory als OCI-Image-Speicher.
Richtlinien-KlÃ¤rung: kÃ¶nnen wir ECR-Repos im Prod-AWS-Account fÃ¼r alle Stages benutzen? Wie kleinteilig mÃ¼ssen wir die Zugriffspolicies schreiben?
Design-Entscheidung: ab welcher Stage wollen wir ECR anstatt Artifactory nutzen?
Design-Entscheidung: in welchen CI-Pipelines wollen wir Images nach ECR kopieren? Zentral in der staging-Pipeline, oder verteilt in allen Build-Repos und mehr?
TODO fÃ¼r alle: ADR lesen bis Architekturrunde am 17.10.2025; wird dort diskutiert
Martin / STeam: wer bekommt Zugriff auf unsere Kafka-UIs?
die Zugriffsrechte sind inzwischen alle auf GitLab-Gruppen abgebildet und die werden von Thorsten verwaltet. Der technische Teil ist also schon verbessert.
Haben wir Regeln wer hier genau Zugriff braucht und bekommt?
Zugriffsvergabe Ã¼ber ART Trio â Anfragen weiterleiten

Agenda 05.09.2025

Frank / Team Zero: zu klÃ¤rende Fragen aus Refinement / Daily:
O2CZERO-2221 Talo Logging - ist das noch aktuell
Umgang mit dem GET "/"
und schlieÃen sich kurz
Martin / STeam: wir brauchen bessere und einheitlichere Log-Levels
Beobachtung aus dem Systemzustands-Check, der tÃ¤glich zeigt wie wenig hilfreich unsere Logs sind
falsche Nutzer-Eingaben sind keine (System-)Errors
ein einmaliger Verbindungs-Retry (z.Bsp. bei REST-API) ist kein Error
Entscheidung: PrÃ¼fen der Logausgaben in allen Teams. Error nur bei technischen Fehlern, die einen Eingriff benÃ¶tigen; nicht in den beschriebenen FÃ¤llen.

Agenda 08.08.2025

Access-Proxy - wie geht es weiter?
Access-Proxy ist bestellt. Aktuelle Hindernisse durch noch nicht aktivierten Leistungsschein
Access-Proxy lÃ¤uft unter anderen Hostnamen:
PROD: pathos.app.db.de
TEST: pathos-test.app.db.de â pathos-test-portal-ui.bsz-abn.cnp-test.comp.db.de
In Arbeit:
Aufbau neue EVU-Test mit Access-Proxy
VorÃ¼bergehender Parallelbetrieb alte und neue EVU-Test
Kundenkommunikation
Â Systemzustandsmeldung
Wie gehen die einzelnen Teams mit den RÃ¼ckmeldungen um?
Ist nachvollziehbar, dass die gemeldeten neuen Fehler behandelt (entweder neues Ticket oder nicht relevant) wurden?
Anpassungen an ÃbersichtÂ
Nummerierungsspalte hinzugefÃ¼gt
Neue EintrÃ¤ge werden hintenangestellt
ExternalDNS ausbauen â neue URLs fÃ¼r betroffene UmgebungenÂ 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-7720150f306eO2CSYS-1436
Schritt 1: IEU
Anpassung ankÃ¼ndigen
Anpassung vornehmen
Anpassung validieren und dokumentieren
Schritt 2: SIT
Anpassung SIT mit Stakeholdern zeitlich abstimmen
Anpassung vornehmen
Anpassung validieren und dokumentieren
Kommunikation an Stakeholder
Schritt 3: E2E
AnkÃ¼ndigen
DurchfÃ¼hren
Validieren und dokumentieren
Frank T./Staging fÃ¼r Nicht-Apps
E.g. curl, infrastruktur-basis-container, flyway
Aktuell passiert dies entweder manuell per renovate (ohne Staging, z.B. curl oder flyway landen parallel auf allen Umgebungen â ohne Testing auf unteren Testumgebungen wie IEU) oder manuell (mit StagingmÃ¶glichkeit, z.B. infrastruktur-basis-container)
Das fÃ¼hrt dazu, dass wir...
Kein Staging fÃ¼r wichtige Images haben
CVEs mitschleifen, z.B. O2CSYS-1720
Wie wollen wir es lÃ¶sen?
VorschlÃ¤ge
Staging Staging (Repo/Pipeline) ausbauen
FÃ¼r unsere eigenen Images (nicht Apps, z.B. infrastruktur-basis-container)
FÃ¼r andere Images (z.B. curl)
Manuellen Prozess aufsetzen und durchsetzen
Renovate-Updates auf bestellsystem-deployment
Update erst nur auf IEU, danach regulÃ¤res Staging (nochmal verifizieren )

Agenda 25.07.2025

Release 23.07. - Lessons Learned: SIT nicht mehr an E2E angleichen, sondern an Release-Stand
aktueller ZustandÂ
SIT â erfolgreich â Versionsstand Ã¼bernommen in SIT-versions.yaml â keine Ãbernahme + Deployment auf E2E
neues Deployment auf die SIT nimmt effektiven Versionsstand der E2E als Ausgangspunkt fÃ¼r das Deployment; nicht den SIT-Versionsstand
NICHT Release-Stand
benÃ¶tigter Zustand
SIT â erfolgreich â Versionsstand Ã¼bernehmen nach SIT versions.yaml
Ausgangspunkt fÃ¼r Deployments auf SIT ist SIT versions.yml und nicht mehr die E2E versions.yaml
Deployments auf E2E und folgende Umgebungen per Full-Update von SIT
Manuelle Ãnderungen an der SIT versions.yaml nur noch in begrÃ¼ndeten AusnahmefÃ¤llen
Umsetzung bei STeam â Review bei SUBP Â schreibt Enabler âÂ 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-7720150f306eO2CSYS-1792
Fragen aus Team Zero/Steam: Was ist der Stand fÃ¼r E2E oder was ist geplant?
E2E wird als Umgebung fÃ¼r TTT-IEU verwendet
ZukÃ¼nftig wieder automatisches Bespielen der E2E
Brauchen wir ein echtes Zertifikat fÃ¼r Demo (aktuell ist dort eines fÃ¼r ABN1)?
Nein â Testzertifikat verwenden
Keystores mÃ¼ssen korrigiert werden â Â
ein Testzertifikat fÃ¼r mehrere Umgebungen ist erstmal ausreichend
Anpassung des EVU-Recorders spÃ¤ter zur PrÃ¼fung von Client-Zertifikaten (Mutual SSL)
Steven / Zero:Â Sollen wir weiterhin User mit lesendem DB Zugriff fÃ¼r ITT/Quest gestatten? Kann das nicht Ã¼ber evu-recorder erfolgen?Â Datenbankzugriffe (extern) - O2C | Order2Cash - ariJa Confluence Â
TemporÃ¤r fÃ¼r TTT-Testumgebungen Lesezugriff ok
Anfang September Anforderungen bzgl. Zugriff auf PathOS Informationen durch ITT/Quest klÃ¤ren und FolgelÃ¶sung konzipieren Â
: Uninstall base-Umgebungen jeden Abend
Nach Umbauten am Deployment erfolgen diese deutlich schneller (~ 6 Minuten)
Uninstall auf base-Umgebungen abends (bis auf PVCs)
Deployment erfolgt manuell bei Bedarf (Starten der Pipeline in bestellsystem-deployment)
Uhrzeit fÃ¼r das Uninstall: 20:00 Uhr
Rollback des Portal-Releases
Unterschiedliche Handhabung leerer Arrays: [] vs null
Wenn required true â immer ein Array setzen
Wenn required false â kann null sein, kann ein leeres oder ein gefÃ¼lltes Array sein
Kein automatisches Umwandeln von leeren Arrays auf null mehr im Bestellsystem

Agenda 27.06.2025

Martin / STeam: KlÃ¤rung Service-VerfÃ¼gbarkeit einzelner Komponenten und Auswirkung auf Gesamt-Bestellsystem-VerfÃ¼gbarkeit
Hintergrund: wir aktualisieren mal wieder die Kubernetes-Version und mÃ¼ssen dafÃ¼r alle K8s-Nodes neustarten. In einem "Kubernetes-Design" funktioniert das komplett ohne Downtime bzw. Service-Unterbrechung, weil alle Komponenten mit mindestens zwei Pods laufen sollten und K8s dafÃ¼r sorgt dass immer einer davon online bleibt.
In unseren Umgebungen sehen wir allerdings mehrere Komponenten mit nur einem Pod, z.Bsp. in (dev-)E2E:
Stammdaten-Bereitstellung
TTK
Camunda-Services
Frage 1: sind das bei SB und TTK nur Deployment-Bugs, die wir schnell hochskalieren kÃ¶nnen? Oder gibt es noch Bugs, die mehr Replicas verhindern?
Deployment-Bug â Umstellen auf Replica 2 â stellt das um â infra/bestellsystem-deployment MR 2051
Frage 2: sind die Camunda-Komponenten so gut gekapselt, dass ein Neustart unproblematisch ist (z.Bsp. weil SV alle Requests queued)?
Nach aktuellem Kenntnisstand ja
Themen SUBP-Team:
Umstellungen Bestellsystem-DeploymentÂ
Ausbau AppMesh zur Vereinfachung Bestellsystem-Deployment
application-setup, database-setup-full werden nach bestellsystem-application umgezogen
Vereinheitlichung der Umgebungskonfigurationen
DNS-Konfiguration
Lokales Bestellsystem + lokale Systemtests
TTTneo-KompatibilitÃ¤t VNP/ENP
DRT-MaÃnahmen
Aufbau PROD
Ãberblick/Kanban Board:Â https://arija.jaas.service.deutschebahn.com/secure/RapidBoard.jspa?rapidView=2569
trivy-operator Ã¼ber CNP "bestellen" â Â
NodePools wÃ¤ren anzupassen (expiration time z.B. 60 m â 30 m)
Ggf. E2E?
Bitte an alle: Base-Umgebungen bei Nichtnutzung abrÃ¤umen
kein Cleanup, aber tÃ¤gliches Downscale wÃ¤re eine Option â prÃ¼fen, ob einfache Umsetzung mÃ¶glich Â
alternativ: Alerts, wenn Base-Umgebungen mehr als 2 Tage "laufen"

Agenda 13.06.2025

150

Planung Umgebungsmapping TTTneo ITU/KTU (siehe PrÃ¤sentation)
ADR 71 - Authentifikation und Autorisierung im Bestellportal (siehe PrÃ¤sentation)
ARD 70 - Weiteres Vorgehen bzgl. System- und Systemintegrationstests â Testing Jour Fixe
Aus DRT:
Wie Verhalten sich unsere Services bzw. einzelne Services wenn Kafka (Ã¤hnliches Szenario bei Keycloak mitdenken) nicht verfÃ¼gbar ist? Wann Soll sich das Gesamtsystem auf nicht mehr verfÃ¼gbar stellen?Â
Erste Betrachtung:
PM: Ohne Kafka nur Lesezugriff (Hinweis an Nutzer wÃ¤re sinnvoll) / Ohne DB â nicht verfÃ¼gbar
CI: Ohne Kafka /ohne DB â nicht verfÃ¼gbar
TTK: Ohne Kafka â nicht verfÃ¼gbar
SV: Ohne Kafka /ohne DB (RDS, Zeebee, Opensearch) â nicht verfÃ¼gbar
Weiteres Vorgehen:Â
Services in einzelnen Teams betrachten, AbhÃ¤ngigkeiten identifizieren
Besprechung im nÃ¤chster Architekturrunde
Verhalten in Anwendungen prÃ¼fen bzgl. Nicht-VerfÃ¼gbarkeit einzelner Infrastrukturservices (z.B. Kafka oder RDS) â Transaktionsklammer richtig gesetzt? Fehlt Transaktionsklammer?
Services in einzelnen Teams auf entsprechendes Fehlerhandlung und Transaktionssicherheit prÃ¼fen

Agenda 26.05.2025

Disaster Recovery Test - Vorbereitungen
Preprod vorbereiten
Protokoll aus 2024:
Aktuelles Testprotokoll:
Anpassungen zur Senkung der Cloud Kosten
Zeigen Wirkung: https://grafana-v2.cnp.comp.db.de/d/de2jmcogii8zkd/aws-cloud-costs?orgId=69&from=now-14d&to=now
Probleme auf IEU wurden behoben
Auswirkungen bitte aufmerksam beobachten, bei Problemen Meldung an STeam
Frank L. Critical/High Findings im Developer-Portal: Findings aus gelÃ¶schten Branches? / Keine Ãnderung durch Container-Umbau? Nimmt er Caches?
Findings aus gelÃ¶schten Branches? â Change Request bereits an Umsetzungsteam vom Developer Portal gestellt, Findings aus gelÃ¶schten Branches zu entfernen
Keine Ãnderung durch Container-Umbau? Nimmt er Caches? â Scan manuell anstoÃen, sonst nur 1 Scan pro Woche
Fragestellung: wie geht man mit Branches um, fÃ¼r die es noch keinen MR gibt?
Fokus auf Master-Branch
Thorsten: Hostnamen sind keine Secrets â keine verschlÃ¼sselten Hostnamen in der Konfiguration
Ticket erstellen und einplanen
Frank T.: (Wiedervorlage, da Inhalt am Thema vorbei besprochen worden ist) MÃ¼ssen wir das Thema readOnlyRootFilesystem auch fÃ¼r GitLab CDAAS Runner einhalten?
FÃ¼r Kaniko (und dann spÃ¤ter auch buildah) verstoÃen wir gegen die Regel runAsNonRoot
GitLab Runner Job PODs sind nur kurzlebige ad-hoc "Batch Jobs", braucht es dafÃ¼r wirklich eine Ãnderung?
Die Ãnderung wÃ¤re recht aufwÃ¤ndig, da wir fÃ¼r jeden Job prÃ¼fen mÃ¼ssen, wohin er schreibt und ob da nicht bereits Daten liegen, die recovered werden mÃ¼ssten, sollte man es mittels "EmptyDirMount" lÃ¶sen...
KÃ¶nnten wir das beim CISO (oder so) erfragen? Oder gibt es fÃ¼r GitLab Runner Job PODs eine Ausnahme?
FALSCH: "Thema ist in Ticket O2CSYS-1666 aufgenommen. Sollte angegangen werden, wenn die restlichen MUSS-Themen erledigt sind." â runAsNonRoot != readOnlyRootFilesystem
Regelung nach RÃ¼cksprache:
Gitlab-Runner mÃ¼ssen readOnlyRootFilesystem einhalten
Job-Runner-Pods mÃ¼ssen das nicht einhalten
Frank T.: CNB Ausbau / Maven Wrapper und sonstige ErgÃ¤nzungen
Wir mÃ¼ssen darÃ¼ber reden, da die Richtung unklar ist, wohin die individuellen App Repos sich hinentwickeln sollen
CNB Ausbau war nicht geplant und kostet viel Aufwand
Maven Wrapper eingefÃ¼hrt (Pipeship)
CIB macht es wieder ganz anders
Keine Einheitliche LÃ¶sung
Caching in 404 fehlt (noch)
Fat-Jar ohne Layer
TODO: Dokumentation
Einplanung in PI 37: Vereinheitlichung der LÃ¶sung (Anpassung CI-Files) + BerÃ¼cksichtigung von System-(Integrations-)Tests

Agenda 16.05.2025

Bing/STeam: ÃberprÃ¼fen und ggfs. Reduzieren der Anwendungsmetriken sowie Metriken der C8-Services (z.B. zeebe). Siehe auch das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1651Â
Zeebe schreibt viele Metriken
Vorschlag:
Schritt 1: Deaktivieren auf den Umgebungen auÃer E2E und EVU-E2E â Â
Schritt 2: Analysieren, wie die Metriken konfiguriert und reduziert werden kÃ¶nnen â Team CIB, erstellt ein Ticket
Spring-Metriken reduzieren (an Team 404-Umsetzung orientieren)
in Team CIB und 404 schon in den jeweiligen Anwendungen umgesetzt
in Team Zero noch offen â Ticket ergÃ¤nzen Â
Thorsten: AbhÃ¤ngigkeit zu CXF / Generell: Umgang mit Dependencies / bestellsystem-parent-pom Â â Â
Verwendung von CXF, Guava prÃ¼fen
Entfernen aus bestellsystem-parent-pom und prÃ¼fen, welche Anwendungen damit Probleme haben
Mehr mit Dependency Management arbeiten
Ãberschreiben von in Spring Boot definierten Versionen vermeiden (erzeugt InkompatibilitÃ¤ten)
Aufteilung in BOM (bestellsystem-bom) und core-dependencies (bestellsystem-parent-pom)Â
Entwurf in Branch â Testen in den Projekten â Merge auf Master
Frank L.: DatenbankgrÃ¶Ãe (z.b. aktuell in IEU ca. 8 GB).
Idee: Auslagern der Json-Blobs auf S3
Vor Go-Live keine KapazitÃ¤t
SpÃ¤ter nochmal betrachten
Partitionen nutzen, um Datenmenge besser zu handhaben

Agenda 28.04.2025

CNP-Risiken von C2S - welche sollten wir fÃ¼r PathOS Ã¼bernehmen?

https://arija.jaas.service.deutschebahn.com/browse/C2SPT-32

Probleme eher beim Aufbau neuer Umgebungen â weniger wÃ¤hrend des Betriebs

https://arija.jaas.service.deutschebahn.com/browse/C2SPT-35

Risiko aufnehmen, allerdings geringe Wahrscheinlichkeit und geringerer Impact âÂ 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-7720150f306eO2CBS-662

https://arija.jaas.service.deutschebahn.com/browse/C2SPT-36

Probleme eher beim Aufbau neuer Umgebungen â weniger wÃ¤hrend des Betriebs

https://arija.jaas.service.deutschebahn.com/browse/C2SPT-29

Risiko aufnehmen, geringere Wahrscheinlichkeit, gleicher Impact âÂ 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-7720150f306eO2CBS-663

https://arija.jaas.service.deutschebahn.com/browse/C2SPT-33

Trennung von CNP-API-basierten Deployments und Bestellsystem-Deployments
Probleme werden in Testumgebungen erkannt â keine Auswirkungen auf Betrieb

https://arija.jaas.service.deutschebahn.com/browse/C2SPT-28

Mitigiert durch CNP-interne Limits â aber grundsÃ¤tzlich auch ein RIsiko fÃ¼r PathOS â Ã¼bernehmen âÂ 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-7720150f306eO2CBS-664
Security-Scanner:
Umgang mit False Positives
Fortify & Branches â als "False Positive" geschlossene Findings kÃ¶nnen auf anderem Branch wieder auftauchen
Entscheidung
Markieren in den jeweiligen Tool (Fortify) bzw. Hinterlegen einer entsprechenden Tool-Konfiguration im Git-Repo
Bzgl. Fortify, siehe auch: https://git.tech.rz.db.de/bestellsystem1/docs/dokumentation/-/wikis/Umgang-mit-Fortify-Ergebnissen#user-content-tag-not-an-issue-link-auf-gitlab
DevPortal-Scanner (Grype, Gitleaks und Compliance) bzw. Trivy in der Bearbeitung priorisieren
Info: portal-ui cnb-builder enthÃ¤lt veraltete Chrome-Version

Agenda 23.04.2025

SITs:
Access Denied beim Zugriff auf Kafka
- STeam schauen sich das gemeinsam an
Setzen des Offsets fÃ¼r einen Kafka-Consumer: welche LÃ¶sung wollen wir umsetzen? Hintergrund: Wir (Zero) hÃ¤tten das zu einer schnellen Problembehebung in der E2E gebraucht, aber keinen aktuell gangbaren Weg gefunden (das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-5498).
, + STeam evaluieren eine LÃ¶sung (kafka-consumer-groups.sh)
Frank T.: MÃ¼ssen wir das Thema readOnlyRootFilesystem auch fÃ¼r GitLab CDAAS Runner einhalten?
FÃ¼r Kaniko (und dann spÃ¤ter auch buildah) verstoÃen wir gegen die Regel runAsNonRoot
GitLab Runner Job PODs sind nur kurzlebige ad-hoc "Batch Jobs", braucht es dafÃ¼r wirklich eine Ãnderung?
Die Ãnderung wÃ¤re recht aufwÃ¤ndig, da wir fÃ¼r jeden Job prÃ¼fen mÃ¼ssen, wohin er schreibt und ob da nicht bereits Daten liegen, die recovered werden mÃ¼ssten, sollte man es mittels "EmptyDirMount" lÃ¶sen...
KÃ¶nnten wir das beim CISO (oder so) erfragen? Oder gibt es fÃ¼r GitLab Runner Job PODs eine Ausnahme?
Thema ist in Ticket O2CSYS-1666 aufgenommen. Sollte angegangen werden, wenn die restlichen MUSS-Themen erledigt sind.
Breaking Changes API
Breaking Changes vermeiden â AbwÃ¤rtskompatibilitÃ¤t leben und Ã¼ben
KompatiblitÃ¤tstests erstellen (alte Nachrichtenversionen mÃ¼ssen noch funktionieren)
Vulnerabilities regelmÃ¤Ãig prÃ¼fen
Tools:
Developer Portal: https://dp.dxc.comp.db.de/
Defect Dojo: https://vistadojo-prd2-igo.vista.comp.db.de/
Vorgehen:
zu Beginn fÃ¼r jedes Team: 1x pro Woche Vulnerabilities prÃ¼fen und behandeln (entweder beheben oder entsprechend dokumentieren)
zunÃ¤chst Behebung auf Master-Branch
bis Ende des PIs konsequente Behebung auch auf E2E + EVU-E2E (bzw. SAT1) + alle anderen Umgebungen
bestehende + neue Vulnerabilities der Stufe hoch und kritisch abbauen bis Ende Sprint 3
bestehende + neue Vulnerabilities der Stufe kritisch, hoch und medium abbauen bis Ende PI 36
Frequenz steigern auf 1x pro Tag in PI 37

Agenda 04.04.2025

Sebastian / STeam: Haben wir Backup bzw. Recoverystrategien fÃ¼r alle Produkte? RDS/Postgres adressieren wir in PI36 schon. Was ist mit dem Rest? Frage kam auf bzgl unserer Kafkas, stellt sich aber sicherlich auch fÃ¼r Zeebe, Opensearch, ...
Bzgl der Kafkas haben wir die Option, diese als "stateless" zu deklarieren (und somit die Verantwortung auf die einzelnen Apps zu verlagern) oder entsprechende Backup- und Recoverystrategien zu etablieren.
Aktuell keine UnterstÃ¼tzung fÃ¼r MSK-Backups Ã¼ber die CNP API. WÃ¤re relevant fÃ¼r einen gleichzeitigen Datenverlust von RDS und MSK. Wahrscheinlichkeit verschwindend gering. Dennoch: zukÃ¼nftig Anforderung an CNP stellen
Momentan Behandlung als Kommunikationsmedium
Zeebe, Opensearch â Camunda âÂ 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-7720150f306eO2CBS-556 in PI 36 ( fachliche Betrachtung in Enabler ergÃ¤nzen)
Martin / STeam: mit den verschiedenen ServiceAccounts und IAM Roles per-Service ist etwas mehr Setup-Aufwand in der CNP-API (d.h. in bestellsystem-ops) notwendig
wir wÃ¼nschen uns dass wir trotzdem alle Roles fÃ¼r alle Umgebungen erzeugen (also auch eine IAM-Role "prod-ifp-mock", obwohl in Prod eigentlich nie ein Mock laufen sollte)
BegrÃ¼ndung: die Einheitlichkeit und Konsistenz der Umgebungen fÃ¼hrt zu weniger KomplexitÃ¤t und ermÃ¶glicht mehr Automatisierung. Das finden wir wichtiger als die initiale Arbeitsersparnis einzelne Teile wegzulassen.
das gleiche gilt im Prinzip auch fÃ¼r die MSK Consumer/Producer Policies. Es wÃ¤re schÃ¶n wenn die auch Ã¼ber alle Umgebungen hinweg gleich sind. Da kÃ¶nnte "Least Privilege" aber ein Gegenargument sein.
Entscheidung: FÃ¼r alle Umgebungen auÃer PROD ok (inkl. MSK Consumer/Producer Policies). PROD sollte separat behandelt/betrachtet werden.
Martin / STeam: wann finden wir denn Zeit fÃ¼r die Doku der Kafka-Topics (vgl. 7.2.)
im RunbookÂ ist leider immer noch ein Fragezeichen, und viele seitdem neue Topics sind nicht eingetragen
STeam kann das Erstellen der Policies Ã¼bernehmen (Anfang in bestellsystem-ops MR 709), aber nur wenn wir die nÃ¶tigen Infos bekommen
wÃ¼rde es uns helfen, wenn wir in bestellsystem-deployment in der _environment.yaml.gotmpl die Attribute 'producer' und 'consumer' einfÃ¼gen?
Wurde erledigt Â

Agenda 07.03.2025

Neue Umgebungen fÃ¼r TTTneo bzw. Parallelbetrieb TTTneo/TTTclassicÂ
8 Umgebungen von TTTneo mÃ¼ssen angebunden werden (1 DEV, 1 TU, 2 SAT, 3 AU, 1 PROD)
TTTclassic benÃ¶tigt weiterhin 2 Umgebungen fÃ¼r ITU und KTU
pathOS hat aktuell 7 integrative Umgebungen
Staging fÃ¼r TTTneo vs. TTTclassic
TTTneo-Staging; Anpassung bisheriges Staging: ABN* + PREPROD nachÂ E2E (nicht mehr parallel und als komplettes BS)?
TTTclassic-Staging: Staging-Prozess fÃ¼r ITU + KTU (mÃ¶glichst einfach, da nur temporÃ¤r)
Nachrichtensignatur an externe Systeme. Erarbeitung eines Vorschlags zum SchlÃ¼sseltausch mit Drittsystemen.
Drittsysteme: TPN Adapter, KOMBau, TBV, Archivierung, Abrechnung
SchlÃ¼sseltausch mit externen Systemen:
Variante Kafka-Topic
Variante Artifactory: Ãffentliche SchlÃ¼ssel + Bibliothek fÃ¼r andere Verfahren zur VerfÃ¼gung stellen
JSON-Struktur in Signatur-Header vermeiden â Aufteilung in 2 HTTP-Header Â
Kurze Frage zu CM-MAEP: Management-Endpoints absichern oder deaktivieren das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-3419
Teams:
PrÃ¼fen, dass nur relevante Actuator-Endpoints freigeschaltet sind
Ãber Ingress-Konfiguration und Network Policies festlegen, auf welche Endpoints zugegriffen werden darf und durch welches System der Zugriff erfolgen darf
PrÃ¼fen, welche Ingresses Ã¼berhaupt noch benÃ¶tigt werden (z.B. NuR-Mock)
Wiedervorlage, Martin/STeam: Umstrukturieren der GitLab-Gruppen
Update tools/ vs. infra/:
Wir haben keine sinnvolle Kategorisierung gefunden; deshalb mÃ¶chte ich den Vorschlag zum Neu-Sortieren zurÃ¼ckziehen.
Wir mÃ¶chten tools/service-certificate-generator nach infra/ verschieben.
Update libraries/ und mocks/:
Vorschlag in Teams-Nachricht: GitLab-Gruppen-Ãnderungen Vorschlag zu den besprochene...
Wenn es keine EinwÃ¤nde gibt, dann kann ich die neuen Untergruppen sofort anlegen und die Repos entsprechend verschiebene.
Auswirkung: Update der git remote URLs notwendig, ggf. Update von Doku und Readmes notwendig
Deadline 14.03.2025 zum Review von Martins Vorschlag. Gibt es keine EinwÃ¤nde, wird sein Vorschlag so umgesetzt.

Agenda 21.02.2025

Frank/Zero: Umgang mit Lup-Metriken (Mimir-Zugang), siehe Reaktion auf https://arija.jaas.service.deutschebahn.com/servicedesk/customer/portal/11/CNPSUP-4400
CNP mÃ¶chte zeitnah einen alternativen Vorschlag zur Anbindung machen, damit wir den im PIP einplanen kÃ¶nnen.
verfolgt die Infos im Ticket und bringt Updates in Team Zero und in zukÃ¼nftiger Architekturrunde ein

Martin/STeam: Im Kontext von Compliance und scm-info Ã¼berlegen wir wie wir mit archivierten GitLab-Projekten umgehen (O2CSYS-1521).

anstatt uralte Repositories nochmal anzufassen wÃ¼rden wir die lieber alle lÃ¶schen

archivierte Repositories, die nicht mehr benÃ¶tigt werden, werden ab 24.02. gelÃ¶scht (kann 30 Tage rÃ¼ckgÃ¤ngig gemacht werden)
mÃ¶chte jemand noch archivierte Repos behalten? (ich wÃ¤re selbst dafÃ¼r infra/bestellsystem-deployment-helm bzw. dessen commit-History zu behalten, das ist aber auch das einzige)
@alle:Â RÃ¼ckmeldung an STeam asap fÃ¼r noch benÃ¶tigte archivierte Repositories
Frank/Team Zero: Umgang mit den Cluster-internen Keycloak-Logins auf Evu-E2E und Evu-Test, siehe auch:Â Kathrin Schleich: Applikationen in Evu-Test und Evu-E2E nicht via Thunderclient zu... verÃ¶ffentlicht in VT Order2Cash / Team STeam am Dienstag, 11. Februar 2025 16:06
Ggf. MÃ¶glichkeit Ã¼ber /etc/hosts Workaround (Vorschlag von )
nimmt das Thema nochmal mit in Team Zero. Bessere AnalysefÃ¤higkeit Ã¼ber Logging/Monitoring schaffen, damit wir auch in Testumgebungen die MÃ¶glichkeiten der spÃ¤teren Produktionsumgebung nutzen und dadurch ggf. vorhandene LÃ¼cken frÃ¼hzeitig aufdecken.
Martin/STeam: WÃ¤re es sinnvoll unsere GitLab-Gruppen weiter zu entwickeln?
tools/ sind "Externe Tools, die wir nicht selbst pflegen", da sind jetzt seit Jahren keine zum rne-common-interface und den excel-tools (werden die benutzt?) hinzugekommen.
Vorschlag:Â Gruppe fÃ¼r alle (intern + ggf. extern) Tools nutzen. Dann wÃ¤re da auch der "Service-Certificate-generator" wieder richtig, und vieles aus infra/ kÃ¶nnte dahin umziehen (fortify-util, installierte-versionen-image, ...)
TODOÂ STeam: konkreter Vorschlag per Teams-Channel, weitere Diskussion dann ggf. in folgender Architekturrunde
apps/ enhÃ¤lt jetzt doch einige Java-Libraries (die aber auch keine APIs sind)
Entscheidung: Gruppe 'libraries/' anlegen. Da passen dann signature-database, logging-utils, parent-pom rein...
Entscheidung: Gruppe 'mocks/' anlegen (fÃ¼r ifp-mock, nur-mock, evu-recorder...).Â
TODOÂ STeam:

372 complete konkreter Vorschlag per Teams-Channel zum Review

Ausfallfreie Secret-Rotation (siehe Keycloak); wie sieht es mit den anderen Infrastrukturkomponenten aus?
Keycloak: Ausrollen neuer Secrets bisher nicht ausfallfrei
prinzipielles Vorgehen:
neue Secrets erstellen, alte Secrets weiterverwenden
Keycloak: speziell 2. Paar ClientID und ClientSecret erstellen (z.B. portal-ui â portal-ui-b)
Apps auf neue Secrets umstellen
alte Secrets lÃ¶schen
Enabler (Team Zero):

373 incomplete dedizierter Test der Secret-Rotation bei der Service-2-Service-Authentifizierung auf statischer Umgebung inkl. A/B-Deployment & DokuÂ Â

PostgreSQL:

374 incomplete Enabler im Backlog von Team STeam

Bei der Dokumentation von Secrets im Runbook an ausfallfreie Secret-Rotation denken; Besonderheiten/Probleme in Architekturrunde einbringen

Agenda 07.02.2025

Thorsten: Branching fÃ¼r parallelen Betrieb von TTTclassic und TTTneo
Zu einem Zeitpunkt X soll ein Branch von SV fÃ¼r TTTclassic erstellt werden. Zeitpunkt X = zu TTTclassic inkompatible Ãnderungen an den Prozessen von SV fÃ¼r TTTneo
TTTclassic: Betrieb des Bestellsystems auf dem letzten funktionierenden Stand auf einer Umgebung. Wartung von Bestellsystem auf diesem Stand hinsichtlich Schwachstellen weiterhin notwendig.
TTTneo: Umstellung des Stagings auf TTTneo
Offene Fragen:
KÃ¶nnen die WartungsaufwÃ¤nde reduziert werden? Z.B. Relevante ArchitekturÃ¤nderungen (z.B. PM â SV Ã¼ber Kafka) vor Zeitpunkt X, reine Wartung nur fÃ¼r SV + IFP-Connector, andere Komponenten werden immer mit neuen Versionen und Features versehen.
Umstellung auf Kafka zwischen PM und SV (O2CBS-487)Â sollte vor dem Branchen umgesetzt werden. bei Planung berÃ¼cksichtigen
Welche Umgebung wird fÃ¼r TTTclassic verwendet? BenÃ¶tigen wir eine neue?
ABN2, es sei denn es gibt neue Anfordungern vonseiten C2S
Wie gestalten wir das Staging/Deployment von TTTclassic?
Idee: RegulÃ¤res Deployment auf ABN2 bis auf Steuerung-Vertrieb. Manuelles Deployment fÃ¼r Steuerung-Vertrieb.
Martin/STeam: CNP bittet uns weniger Metriken zu erfassen, die Datenmenge fÃ¼hrt zu instabilen Grafana-Agents (CNPSUP-4363)
persÃ¶nliche Vermutung: wir haben viele default-Metriken (aus Spring/Micrometer, OpenTelemetry, AppMesh, ...) von denen wir nicht mal wissen ob sie nÃ¼tzlich sind und wie wir sie abschalten kÃ¶nnten
wie kÃ¶nnen wir damit umgehen?
Scraping-Intervall auf mindestens 30 sec. setzen
Enabler: Anhand eines Service (+ ggf. Steuerung-Vertrieb) prÃ¼fen, welche Metriken wir schreiben Â (âÂ 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-7720150f306eO2CBS-588) Â
Martin/Sebastian/STeam: Einheitliche Benennung Kafkatopics: Wir sollten ggf ein einheitliches Format fÃ¼r die Benennung unserer Kafkatopics einfÃ¼hren. Hier sind wir aktuell recht uneinheitlich. Ggf analog zu https://www.confluent.io/learn/kafka-topic-naming-convention/?
Aktuell listet das Runbook die folgenden Topics: https://bestellsystem1.gitpages.tech.rz.db.de/docs/runbook/02-architecture/07_deployment_view.html#chapter-internal-systems
Es existieren aber auch andere wie zBÂ "tbvAbsicherung" oder "versandErgebnis"
Der CNP-Validator bemÃ¤ngelt GroÃbuchstaben in Topics. STeam geht hier auf die CNP zu, das zu Ã¤ndern das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1484 und CNPSUP-4362 (offizielle Doku von Kafka sieht keine derartige Limitierung vor) => der Validator ist angepasst Â
TODO fÃ¼r Zero und CIB: Vereinheitlichung der Topic-Namen "tbvAbsicherung" und "versandErgebnis" auf Kleinschreibung mit Bindestrichen
TODO ÃberprÃ¼fung der Topic-Namen im Runbook (alle Teams)
Frank T. / Henrik Scholl: Laut Richtlinie darf die ABN und PROD Umgebung nur via PAN benutzt werden
Laut CNP ist es nur PROD, dass nur per PAN benutzt werden darf
Das merkt man ja auch an der Zugriffskonfig â DB Admin User fÃ¼r PROD verpflichtend
"FÃ¼r Editor bzw. Schreibberechtigungen in der CNP-PROD-Umgebung (allgemein in PROD-Umgebungen) dÃ¼rften nur privilegierte 2er Account-ACAT-Gruppen eingetragen werden (beginnend mit der Zeichenkette gmu). Die Autorisierung von nicht-privilegierten ACAT-Gruppen ist nicht gestattet. (Bitte den Support bei SpezialfÃ¤llen kontaktieren.)"
https://cnp.gitpages.tech.rz.db.de/core/docs/cnp/latest/cnp-q-a-session/acat.html
Systel Richtlinie: https://dbsw.sharepoint.com/sites/sw-informationsecuritydbsystel/SitePages/Nav%20(Confluence)/Vorgaben%20in%20Arbeit/Privileged%20Access%20Management.aspx#:~:text=f%C3%BCr&text=pan&text=welche&text=Umgebungen
Ist das ein Clash DB InfraGO (geltend fÃ¼r CNP) vs. DB Systel?
Enabler: Umstellung Umgebungen auf der ABN-Stage auf PAN-Client (âÂ 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-7720150f306eO2CBS-589) Â

Agenda 27.01.2025

Access-Proxy:
Infos: https://db-planet.deutschebahn.com/pages/sipsteam/apps/content/application-proxy-mobile-app-gateway
Funktioniert fÃ¼r B2B Guests, siehe https://db-planet.deutschebahn.com/pages/b2b-accessmanagement/apps/content/b2b-accessmanagement
NuR-Benutzer werden als B2B Guests angelegt â Nutzung des Access-Proxys mÃ¶glich
TTTneo: Durchstich Bestellsystem â TPN Ã¼ber eigenes MSK-Cluster letzte Woche erfolgreich. Allerdings musste MSK-Cluster in primÃ¤res Subnetz gestellt werden.
Wenn wir das fÃ¼r TPN grundsÃ¤tzlich Ã¼ber unser MSK-Cluster umsetzen, mÃ¼ssen wir das fÃ¼r alle Umgebungen anpassen, die an TTTneo/TPN angebunden werden. Werden hier Probleme erwartet? Gibt es alternative VorschlÃ¤ge?
TPN kann kurzfristig kein eigenes MSK-Cluster betreiben.
Trennung internes/externes MSK-Cluster? Betrachtung Berechtigungen & Backup/Recovery notwendig.
Entscheidung: Wahl der Alternative: 1 MSK-Cluster im primÃ¤ren Subnetz mit EinschrÃ¤nkung der IP-Range
Schrittweise Umstellung von JDK 17 auf JDK 21 (Corretto)
KÃ¶nnen die RDS-Instanzen aus dem primÃ¤ren Subnetz genommen werden (zumindest in hÃ¶heren Umgebungen)?
Anmerkung Martin/STeam: wenn wir die Subnetze Ã¤ndern, dann kann die fachliche BetriebsfÃ¼hrung nicht mehr drauf zugreifen (vgl. O2CZERO-4892)
Entscheidung: Festlegung der Vorgehensweise im Zusammenhang mit der spÃ¤teren DevOps-BetriebsfÃ¼hrung â dann ausfÃ¼hrliche Dokumentation
Martin / STeam: Stage von ABN2 Ã¤ndern?
Wenn wir auf ABN2 den Durchstich zu TTTneo herstellen wollen und dafÃ¼r doch noch Anpassungen erwarten, dann wollen wir vermutlich Ã¶fter als im 2 Wochen Release-Zyklus neue Image-Versionen deployen.
WÃ¤re es sinnvoll ABN2 dafÃ¼r im Staging-Prozess anders einzusortieren, auf Ebene von SIT oder IEU?
Entscheidung: Abwarten bis das weitere Vorgehen bzgl. TTTneo geklÃ¤rt ist. Bis dahin keine Ãnderungen an ABN2.
Bing / STeam: PR-LPRV: Anwendungsspezifische Consumer/Producerrechte fÃ¼r Kafkatopics:Â das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1471
Dokumentation der Producer/Consumer im Runbook: https://bestellsystem1.gitpages.tech.rz.db.de/docs/runbook/02-architecture/07_deployment_view.html#_kafka
TODO fÃ¼r alle Teams: PrÃ¼fung, dass die Dokumentation im Runbook korrekt ist
TODO fÃ¼r alle Teams: Ãbernahme der Konfiguration, KOMBau-Konfig kann als Blaupause verwendet werden (Consumer.yaml, Producer.yaml)
Frank L. / Zero: Fehlerbehandlung Validierungsfehler (evtl. auch fÃ¼r andere Fehler: gibt es best Practices - Fehlertopics scheinen mir nicht immer optimal)
Schema-Validierung bei Producer und Consumer
Nicht-lesbare Nachrichten in DLQ-Topic sammeln, Monitoring auf diesem Topic mit Alert, ggf. Verarbeitung weiterer Nachrichten von diesem Topic stoppen

Agenda 29.11.2024

Frank/Martin/STeam: Artifactory-Downtime am 7.12.
ProblemstellungÂ
CNP-MaÃnahmen dazu,Â Daniel Werdermann: 07.12.2024: Artifactory Update + Downtime
Wollen wir das Bestellsystem weiterentwicklen um kÃ¼nftig besser damit umzugehen?
fÃ¼r den Betrieb
fÃ¼r Dev-Pipelines?
Wir hatten schon Ã¼ber ECR als zusÃ¤tzliche OCI-Quelle gesprochen, doch das nÃ¼tzt uns relativ wenig weil wir auch Datei- und Helm-Repos benÃ¶tigen. Und fÃ¼r Dev dann auch Maven+NPM.
LÃ¶sungsfindung:
Kopieren der Images nach ECR Ã¼ber entsprechenden Pipeship-Job
SL-Ausschluss (in SL-Dokumentation mit aufnehmen): Wenn Artifactory ausfÃ¤llt, kÃ¶nnen wir keinen Hotfix erstellen
Durchstarten von Nodes beim Ausfall von Artifactory mÃ¶glich
Helm-Charts entweder (wÃ¤re zu testen)
in S3 Ã¼ber Helm S3-Plugin (Race-Condition bei index.yaml-Editierung)
oder in ECR (siehe https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html)
Enabler:
Umgang Nicht-OCI-Artefakte bei Verwendung von ECR (CA-Zertifikaten usw.)
Helm-Charts S3 vs ECR
ECR in Pipelines einbinden
auf Jan bzgl. Access-Proxy fÃ¼r Portal zugehen (lÃ¤ngere Patchfristen)
Nach ErstklÃ¤rung â Wiedervorlage in Architekturrunde
Â DR-Test:
Camunda-Backup-Konzept (siehe https://docs.camunda.io/docs/self-managed/operational-guides/backup-restore/zeebe-backup-and-restore/)
Team CIB: Backup-Vorgehen testen und dokumentieren â Enabler fÃ¼r PI 36
DB-Schnitt:
am Ende vom DR-Test liefen 2 DB-Cluster parallel â Migration im laufenden Betrieb wÃ¤re notwendig
DB-Schnitt doch anders wÃ¤hlen?
zu beachten:

DB Gold: 99,91% VerfÃ¼gbarkeit im Jahresmittel, RTO: 2 Stunden Erwartete Datenbank-GrÃ¶Ãe (AVT): ca. 2 TB

Zugriff auf die Datenbank nur von PAN aus - dort maximale Storage-Size: 50 GB
UKA-Ausfall-Zeit-Ziel pro Jahr: <12 Minuten
ADR ausarbeiten â + Architekturrunde
DB-Instanztyp:
Multi-AZ RDS DB-Cluster empfindlich fÃ¼r deaktivierte KMS-Keys
RisikoabwÃ¤gung: Instanztyp beibehalten oder Alternativen nochmal in Betracht ziehen?
ADR bzgl. DB-Cluster Ã¼berarbeiten: + Architekturrunde
Norbert: Wo sollen wir Alles dokumentieren? (Confluence, Runbook, GIT)
Testprotokolle: Weiterhin in Confluence
WiederanlaufplÃ¤ne: im Runbook

Agenda 15.11.2024

DR-Test-Dokumentation: https://arija-confluence.jaas.service.deutschebahn.com/pages/viewpage.action?pageId=386382061
Martin/STeam: Unsere Anwendungen haben sehr unterschiedliche Datenbank-Einstellungen in den application.yml-Dateien (spring.flyway, spring.jpa, spring.datasource). KÃ¶nnen/wollen wir das mal vereinheitlichen?
Timeout-Werte und sonstige relevante DB-Parameter mÃ¶glichst vereinheitlichen und im Configuration-Management-Abschnitt dokumentieren
/ Â / Konfiguration in Teamanwendungen betrachten und Abweichungen von Default-Werten begrÃ¼nden
Wiedervorlage in nÃ¤chster Architekturrunde
STeam: Archivieren von bestellsystem-deployment-helm
Wird von Team 404 noch verwendet
Kann noch nicht archiviert werden
Empfehlung: Ãberschreiben der Werte in der values.yml
ZAP-Test wird von AT/Review-Umgebung Ã¼ber ci-files auf andere Umgebung umgestellt. Team STeam stellt neue Version von ci-files zur VerfÃ¼gung (Zeitpunkt abhÃ¤ngig von DR-Test-Umfang).
CI & TTK prÃ¼fen im health-Check ob Partnerdaten vorhanden sind, dies fÃ¼hrt zu Problemen im neuen Kubernetes-Job zum BefÃ¼llen der Daten in der KB (Team ZERO)
Health-Check unabhÃ¤ngig von vorhandenen Partnerdaten â Smoketest prÃ¼ft ValiditÃ¤t der Partnerdaten nach dem Deployment
Alternativ: Einspielen der Partnerdaten via Sidecar
Weiteres Tracking des Themas in CI/CD-Runde
Diego/Team 404: WebSSO fÃ¼r E2E-Umgebungen: Das Portal unterstÃ¼tzt Keycloak und WebSSO als Login-Maske, aber WebSSO wird momentan nirgendwo verwendet. Sollen wir fÃ¼r (einige) E2E-Umgebungen nicht WebSSO einsetzen? WebSSO kann nicht automatisch getestet werden, aber fÃ¼r Umgebungen mit ausschlieÃlichen manuellen Tests kann es Sinn machen, WebSSO als Login-Maske zu konfigurieren.
PrÃ¼fung, ob ABN1 oder ABN2 an WebSSO angebunden werden kann

Agenda 01.11.2024

Flyway: Entscheidung fÃ¼r Umsetzungsvariante
Enscheidung:Â Variante 4 per Default, Variante 1 bei Bedarf (wie z.B. SV)
Flyway-Bibliotheken mÃ¼ssen aus Images entfernt werden
Bei lokaler Entwicklung ggf. mit Maven-Profilen arbeiten
CNB: wird beibehalten mit Ausnahme von SV und zukÃ¼nftig ggf. Projekten mit Bedarf an Multi-Modul/-Image-Umsetzung.
Systemtests laufen maÃgeblich auf Base-Umgebungen. Ãnderungen an Systemtests fÃ¼hren zu einem MR. dessen Pipeline die Tests auf IEU ausfÃ¼hrt
Pipeline-Id + ENVIRONMENT-Wert anpassen/Ã¼berschreiben
& stimmen sich bilateral ab
Diego: Wie gehen wir mit der Token-Rotation fÃ¼r den Azure-AD-Token um, den die PM fÃ¼r die Verbindung mit NuR verwendet? Momentan muss der Token nach 1 Jahr ersetzt werden.
Im Entwicklungshandbuch zu dokumentieren
Martin/STeam: Wann wollen wir nochmal PostgreSQL updaten? Und wie oft wollen wir das vor dem Live-Gang noch machen? â geklÃ¤rt?
ein Update auf v16 wÃ¤re sinnvoll, wollen wir das machen und wann? Liegt in PI34S5: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1318
ab Ende 2024 kÃ¶nnten wir auch auf v17 gehen: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1319
Background: PostgreSQL released jÃ¤hrlich im September/Oktober und unterstÃ¼tzt major Versionen fÃ¼r 5 Jahre, der AWS-RDS-Support fÃ¼r Versionen lÃ¤uft immer ein paar Monate nach. Generell ist es wÃ¼nschenswert jetzt im Dev-Stadium eine mÃ¶glichst neue Version zu benutzen, damit im Live-Betrieb mÃ¶glichst viel FlexibilitÃ¤t und Zeit bis zu einem Zwangs-Update bleibt.
STeam: ZAP Scans in Build-Pipeline oder anderem Kontext?
In Enabler das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1325 wurde ein Trigger-Job in bestellsystem-deployment umgesetzt. Der Trigger-Job triggert die Gitlab-Repo owasp-zap-scanner um die Zap-API-Scans und Zap-Baseline-Scans auszufÃ¼hren. Bsp. Pipeline: https://git.tech.rz.db.de/bestellsystem1/infra/bestellsystem-deployment/-/pipelines/39649981
Zur Abstimmung: Gegen welche Umgebung (nach welchem Deployment) soll der Trigger-Job angestoÃen werden. WÃ¤re IEU an der Stelle passend? Info: die Zap-Scans dauert es ca. 30 Min
Entscheidung:
Tests auf Umgebung IEU
EinschrÃ¤nkung der Tests nur bei Ãnderungen von Services mit Zugriff aus dem Internet: Common Interface, Portal-Middleware, Stammdaten-Bereitstellung
zukÃ¼nftige Alternative fÃ¼r Whitesource?

Agenda 11.10.2024

LÃ¶sungsansatz fÃ¼r AT/Review-Deployment in Bezug auf der Umstellung auf Helmfile abstimmen: Alternative LÃ¶sung und aktuelle Nutzung der AT/Review-Umgebung findet man in das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1324
Nutzung der Umgebungen:Â
Nutzung der AT-/Review-Umgebung maÃgeblich fÃ¼r ZAP-Scans â kann auf Base-Umgebung stattfinden (sinnvoll: DurchfÃ¼hrung in bsz-abn-Umgebungen)
Team 404: Nutzung fÃ¼r Cypress-Tests â kann auf Base-Umgebung stattfinden
Team CIB: Nutzung fÃ¼r KITs â Deployment bereits separat umgesetzt
Varianten
Variante 1: Beibehaltung der AT/Review-Umgebungen
Replizierung von Helmfiles in die jeweiligen Projekte notwendig
Durch die Projektteams umzusetzen
Variante 2: Verwendung der Base-AT-Umgebung fÃ¼r Cypress- und KI-Tests
Zentrale Verwaltung der Deployment-Konfiguration in bestellsystem-deployment
"Basiskonfiguration" wird von STeam erstellt
Aufwand vergleichbar zu Variante 1
Entscheidung:
Umstellung auf Variante 2
Vorgehen wird in CI/CD-Runde detailliert
Vereinheitlichung (KITs von SV) nachrangig zu Umstellung von z.B. Team 404 Cypress-Tests
Flyway
Umsetzungsvarianten:
Variante 1 (siehe SV): separates Maven-Modul + separates Container-Image, Images werden via Dockerfile erstellt
Ablauf
Beim Erstellen der Images im Buildprozess wird auf Dockerfile zurÃ¼ckgegriffen. Dabei wir direkt ein separates Flywayscripts-Image fÃ¼r SV gebaut. Siehe Diagramm.
Beim Helm-Deployment wird ein Kubernetes-Job ausgefÃ¼hrt, der das Image startet. Dadurch wird automatisch die Migration durchgefÃ¼hrt. AnschlieÃend wird der Container wieder beendet. Siehe Diagramm.
Vorteile/Nachteile:
Vorteile:
Application Image enthÃ¤lt keine unbenÃ¶tigten Dateien (Flyway-Skripte)
Flywayscripts-Image wird parallel zu Application-Image gebaut
Nachteile:
Umbau des Buildprozesses in allen Projekten notwendig (siehe Umstellung CNB â Dockerfile)
Updates/Wartung alles Images muss durch das jeweilige Projektteam sichergestellt werden
Variante 2: Image dynamisch erstellten und Flyway-Migrationsskripte aus Applikations-Image auslesen
Ablauf
In der CI/CD-Pipeline werden nach dem Erstellen des OCI Images der Application die Flyway-Skripte aus dem Image als Artefakte herausgeschrieben. Im Folgeschritt wird dynamisch ein Flywayskripte-Image gebaut (siehe Diagramm); kann ggf. parallelisiert werden.
Die AusfÃ¼hrung kann wie in Variante 1 erfolgen.
Vorteile/Nachteile
Vorteile:
Funktioniert auch mit CNB â Anpassungen maÃgeblich in CI/CD-Pipeline
Nachteile:
ErhÃ¶ht weiter die Logik/KomplexitÃ¤t der Pipeline
Variante 3: Kombination aus CNB fÃ¼r Applikation + Dockerfile fÃ¼r Flywayscripts-Image
Ablauf
In jedem Projekt mit Flywayskripten wird ein Dockerfile ergÃ¤nzt fÃ¼r das Erstellen eines Flywayscripts-Images. Der Buildprozess wird so angepasst, dass er zusÃ¤tzlich zum Application Image ein Flywayscripts-Image bauen kann (unter Verwendung des Dockerfiles)
Die AusfÃ¼hrung kann wie in Variante 1 erfolgen.
Vorteile/Nachteile
Vorteile
Application Image enthÃ¤lt keine unbenÃ¶tigten Dateien (Flyway-Skripte)
Nachteile
Updates/Wartung des Flywayscript-Images muss durch das jeweilige Projektteam sichergestellt werden
ZusÃ¤tzliche Logik in Pipeline bzgl. Entscheidung: CNB, Dockerbuild oder Kombination aus CNB + Docker
Martin: Wissen wir eigentlich dass wir zwingend ein eigenes Image fÃ¼r die Flyway-Scripte brauchen? sonst schlage ich vor Variante 4: Der Build bleibt so wie jetzt, wir schreiben nur einen eigenen Flyway-Setup-Job
Ablauf
Wir bauen die Anwendung wie bisher
Beim Deployment starten wir einen Flyway-Job und mounten die Scripte aus unserem Application Image
Vorteile/Nachteile
Vorteile
Keine Ãnderung am Build-Prozess nÃ¶tig
Keine zusÃ¤tzlichen Images zu pflegen und abzusichern (unter der Annahme dass die Open Source Flyway Images okaye QualitÃ¤t haben)
Nachteile
Application Image enthÃ¤lt die Flyway-Skripte, die kÃ¶nnte man als unbenÃ¶tigten Dateien sehen
Entscheidung:
Annahme Minimal Image: Keine Flyway-Bibliotheken. Flyway-Migrations-Skripte (*.sql) kÃ¶nnen enthalten sein.
Entscheidung zwischen Varianten 3 oder 4. Team Zero und Team 404 besprechen das nochmal im Team.
Deployment-Job vs. Init-Container zu klÃ¤ren
Extra Termin fÃ¼r Thema
CNB (Fortsetzung)
Weiteres Vorgehen abhÃ¤ngig von Entscheidung zu Flyway
Wollen/Brauchen wir eine einheitliche LÃ¶sung im Bestellsystem oder ist es ok, wenn einzelne Projekte bei Bedarf vom "Standard" abweichen (Bsp. aktuell: SV)?
Entscheidung: tbd

Agenda 27.09.2024

CI-Files in den Projekten auf Version 3.6.0 aktualisieren (helmfile + C8) bis heute EOB
CNB: behindernde EinschrÃ¤nkungen von CNB bzgl. Multi-Modul-Projekten und Multi-Image-Projekten; (wie) lÃ¤sst sich das mit CNB lÃ¶sen? Was ist die Alternative?
target-Verzeichnis in build_application_image_heroku hartkodiert
Stellen:Â
https://git.tech.rz.db.de/bestellsystem1/infra/ci-files/-/blob/master/dist/git/customize-job-build_application_image_heroku.yaml?ref_type=heads#L533
https://git.tech.rz.db.de/bestellsystem1/infra/ci-files/-/blob/master/dist/git/customize-job-build_application_image_heroku.yaml?ref_type=heads#L534
https://git.tech.rz.db.de/bestellsystem1/infra/ci-files/-/blob/master/dist/git/customize-job-build_application_image_heroku.yaml?ref_type=heads#L773
FÃ¼r Projekte konfigurierbar machen?
Job kann pro AusfÃ¼hrung nur 1 Image bauen. Werden mehrere Images benÃ¶tigt, mehrmalige AusfÃ¼hrung notwendig â negative Auswirkung auf Performance in der Pipeline
Test-Report aus dem Build wird verworfen â zusÃ¤tzliche Logik in Pipeline fÃ¼r Testauswertung notwendig
Job-KomplexitÃ¤t: build_application_image_heroku hat ca. 900 Zeilen, Build-Job in SV: 40 Zeilen + 180 Zeilen in 5 Dockerfiles
Image-GrÃ¶Ãe: mit CNB > 500 MB, nach Umstellung auf Dockerfile ~300 MB
Abgesehen vom Umstellungsaufwand: Mit welchen Nachteilen mÃ¼ssten wir leben, wenn wir auf CNB verzichten?
SV-Variante des Image-Bauens nachvollziehen und in STeam diskutieren
Wiedervorlage in Architekturrunde am 11.10.
End of support fÃ¼r AWS AppMesh am 30.09.2026 im Zusammenhang mit das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-6343
Ticket O2CCIB-6343 zurÃ¼ckstellen, bis eine Entscheidung Ã¼ber das weitere Vorgehen getroffen wurde. Danach einplanen.
Review von ADR-67, https://git.tech.rz.db.de/bestellsystem1/docs/runbook/-/blob/feat/O2CZERO-4414-adr-anbindung-stationsportal/02-architecture/103-adrs/0067-datenbereitstellung-stationsportal.adoc?ref_type=heads
Frank (aus CI/CD-Runde): Prod und Dev Repos fÃ¼r Apis (renovate erstellt aktuell MRs fÃ¼r alles)
Ziel fÃ¼r alle Projekte: Renovate berÃ¼cksichtigt nur "getaggte" Versionen von APIsÂ
GewÃ¼nscht ist: nur die "getagged" VersionenÂ sollen released werden. => also Benutzen des ADR58-Release-Workflows auch fÃ¼r APIs und Libraries => O2CSYS-1210
Einfache Variante: Eine CI/CD-Pipeline, Ziel-Repository ist abhÃ¤ngig von Tag (â Prod) oder "Nicht Tag" (â Dev)
nochmal in STeam abstimmen
Frank L./Team Zero: Talo-Logging nur fÃ¼r Cockpit? das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-2221
Neue Variante von Netcool/Cockpit verwenden: nur definierte Alarme an Netcool senden, nicht mehr das komplette Log; Talo-Logging damit nicht mehr notwendig
stellt Links zur Dokumentation zur VerfÃ¼gung
Wiedervorlage in Architekturrunde am 11.10.
STeam/Michael: Kafka-ui generell (intern) deployen? Hilft beim prÃ¼fen der FunktionalitÃ¤t von MSK
Kafka-UI steht auf dem Dev-Cluster bereit. Was ist mit generell gemeint?
In ABN und PROD mÃ¼ssen die Zugriffsrechte minimal sein (Least-Privilege-Prinzip) â keine Schreib- oder LÃ¶schrechte
Bereitstellung aktuell Ã¼ber Port-Forwarding; ZurverfÃ¼gungstellung ohne Port-Forwarding nur mit entsprechender Authentifizierung (z.B. Anbindung an Keycloak)
KlÃ¤rung mit Michael, Umsetzungskonzept

Agenda 06.09.2024

Festlegung von Trust Boundaries â Teil der Bedrohungsanalyse mit Security Engineers Anfang Oktober
PI 33: Produktionsumgebung: Jeder Services lÃ¤uft mit einem eigenen Datenbank-Cluster? (siehe auch 8.4.2024)
ADR-65. Aufteilung der Datenbank-Instanzen 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-7720150f306eO2CBS-493Â
eigene DB fÃ¼r SV + IFP-Connector
Status Ã¤ndern auf Akzeptiert
ADR 66 - Nutzung von helmfileÂ 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-7720150f306eO2CBS-505
Thema in PI 34 einplanen
Team-Enabler fÃ¼r Umstellung erstellt ; jedes Team soll min 1 Service umstellen
Feedback zu ADR wird noch gegeben (von Team STeam)
Frank L./Team Zero: Besprechung des ADR Datenbereitstellung fÃ¼r das Stationsportal https://git.tech.rz.db.de/bestellsystem1/docs/runbook/-/blob/feat/O2CZERO-4414-adr-anbindung-stationsportal/02-architecture/103-adrs/0067-datenbereitstellung-stationsportal.adoc?ref_type=headsÂ WICHTIG - noch vor PI-Planning 34
Keine Logik in SV zur "Filterung" von Nachrichten fÃ¼r externe Systeme (Nachrichtenstatus)
Konverter sollten alle Nachrichten aus dem AV-Topic lesen und Filterung selbst vornehmen
Datenstruktur fÃ¼r Stationsportal (fÃ¼r aktuelles Vertragsdaten-Dritte-Topic) wird im Laufe von PI 34 geklÃ¤rt (und im ADR nachdokumentiert)
passt ADR an

Agenda 09.08.2024

AnkÃ¼ndigung von STeam: Zusammenlegung der DEV-Datenbanken sowie Zusammenlegung der Datenbanken Â EVU-Test und EVU-E2E (ADR-59)
Umstellungsdetails:
Umsetzung: PI 33 O2CBS - S4 - O2CSYS, das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1123
Nur Daten von Keycloak werden mitgenommen
Downtime fÃ¼r Umschwenken von IEU/SIT/E2E wird in Teams-Kanal angekÃ¼ndigt
Wie ist der Kommunikationskanal Ã¼ber Downtime fÃ¼r Umschwenken von EVU-Test/EVU-E2E? Keine Daten werden mitgenommen auÃer KeyCloak!
Abstimmung bzgl. E2E und EVU*-Umgebungen mit TTT-Koordinatoren notwendig!
Keine Umstellung von SIT, E2E, EVU-Test und EVU-E2E bis 4.9. (Zeitpunkt Entscheidung Go-Live 2025)
SV-Datenbank wird nach Camunda-8-Umstellung sowieso gelÃ¶scht
Info: Update von CA-Cert durch Amazon am 22.8. (Hintergrund/Links in O2CSYS-871 und O2CSYS-1068)
Einbindung Netzgrafik in das Bestellportal - Fortsetzung
Frontend Ã¼ber Angular-Bibliothek
AbhÃ¤ngigkeit durch Angular-Version
Datenaustausch (relevante Netzdaten) Ã¼ber Kafka
Backend
berechnet Netzgrafiken - teilweise anhand von Benutzerfiltern; dauert teilweise 3-4 Minuten (ressourcenlastig)
VorschlÃ¤ge zur Umsetzungsvarianten von KuK:
Bibliothek zur Einbindung in eine BS-eigene Komponente
Netzlotse wird als Docker Image zur VerfÃ¼gung gestellt und in das Bestellsystem-Deployment eingebunden
Konsequenzen der KuK-VorschlÃ¤ge: Betrieb "fremder" Komponenten im Bestellsystem mit sÃ¤mtlichen Konsequenzen
Alternative: Betrieb des Netzlotsen durch KuK
Zugriff Ã¼ber synchrone Schnittstelle auf Netzlotse (durch z.B. Portal-Middleware)
KuK mÃ¼sste auch SL Gold anbieten
Variante: Netzlotse bei KuK betreiben und als optionales Feature behandeln; vorberechnete Netzgrafiken zwischenspeichern; wenn nicht verfÃ¼gbar keine Filteroption
Feature-Ticket ergÃ¤nzen
Aus Security-Assessment: Code-Review Enforcement in Gitlab?
Gegen Enforcement spricht die schnelle Fehlerbehebung im Falle eines Notfalls
Kein Enforcement in Gitlab um Fehlerbehebungen nicht zu behindern
Code-Reviews sind bereits Bestandteil der DoD
RÃ¼ckfrage bei Security Engineers bzgl. Formulierung in DoD
Neue Umgebungen: Was ist der Prozess / was sind die ZustÃ¤ndigkeiten des Deployments und der Konfiguration (und des Monitorings) fÃ¼r das deployment der bsz-Apps? Hintergrund: PREPROD ist noch nicht vollstÃ¤ndig mit allen bsz-Apps bespielt worden. Insbesondere die Konfiguration der Apps untereinander ist von Interesse! Wunsch: Vorgehen fÃ¼r ABN1/ABN2/PROD planen.
Smoketest:
Je 1 Bestellung Ã¼ber beide EingangskanÃ¤le (CI und Portal-UI) auslÃ¶sen und prÃ¼fen, ob sie in den entsprechenden Kafka-Topics (â IFP) ankommen
Bei Produktion: Abstimmung mit TTT notwendig
Abstimmung mit und Â
Gemeines Review der Umgebungskonfiguration mit allen Teams pro Umgebung und bei Bedarf
Dokumentation der Umgebungen im Runbook

Agenda 12.07.2024

Einbindung Netzgrafik in das Bestellportal
C2S Capability: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eC2SLS-2090
Netzgrafik Beispiel: https://netzlotse-frontend-kuk-iat.cnp-test.comp.db.de/netzgrafik
DB Backup & Recovery: StÃ¶rfÃ¤lle, Wiederherstellung, Konsequenzen
Kein DB-Split, da es bei Wiederherstellung die KomplexitÃ¤t deutlich erhÃ¶ht
EingÃ¤nge von SV sollten auf Kafka basieren
Kafka-Backup separat zu betrachten
RocksDB in Camunda 8 berÃ¼cksichtigen!

Agenda 17.05.2024

Aktueller Stand Systemtests
Aufgabe fÃ¼r das kommende Sprint-Planning: KlÃ¤rung bei 404 und CIB, ob Jan 1-2 Tage bzgl. Selenium-Tests aushilft
Erste AusfÃ¼hrung mit dynamischen Umgebungen immer noch hÃ¤ufig fehlerhaft? â zunÃ¤chst Selenium-Problematik betrachten
ART-Enabler fÃ¼r PI 33 vorbereiten Â
O2CBS-353: Die Systemtests sind in Anlehnung an die KITs von SV refaktoriert
Aus PI 33 Planung entfernen
Umstellung Architekturdokumentation
Architekturdokumentation ins Runbook Ã¼bernehmen, bisheriges Repository archivieren
O2CBS-408: Vorbereitung Produktivsetzung: Ausarbeitung des Runbooks
Testdaten fÃ¼r Kundendaten-Bereitstellung (bis 300 Partner Ã¼ber SQL in Datenbank insert): Die SQLs in Helm-Chart oder in Artifactory? siehe ADRÂ 47
Falls es eine Pflegeschnittstelle gibt â Testdatenimport Ã¼ber Schnittstelle
Daten, die in integrativen Umgebungen aus externen Systemen geladen werden, werden Ã¼ber (Wire-)Mocks zur VerfÃ¼gung gestellt
Neuer ADR + Enabler Â

Agenda 19.04.2024

Runbook-Vorstellung:
Git-Repo: https://git.tech.rz.db.de/bestellsystem1/docs/runbook
Gerenderte Variante: https://bestellsystem1.gitpages.tech.rz.db.de/-/docs/runbook/-/jobs/207310721/artifacts/public/doctoolchain/04-runbook/05-processes/01-configuration-management.html
TTT-Produktivsetzung in Confluence: https://arija-confluence.jaas.service.deutschebahn.com/pages/viewpage.action?pageId=316973165

Agenda 8.04.2024

Frage von Team Zero: Gibt es eigentlich ein Rechte- und Rollenkonzept fÃ¼r das neue Bestellsystem?
Dokumentation fÃ¼r Entwicklungs-/Betriebsrollen
Dokumentation technischer Benutzer und Rollen
Dokumentation fÃ¼r CI
Dokumentation fÃ¼r Portal
: Template fÃ¼r Dokumentation + Enabler erstellen
Produktionsumgebung: Jeder Services lÃ¤uft mit einem eigenen Datenbank-Cluster? (Problem in der Metrikerhebung der Stammdatenbereitstellung fÃ¼hrt zu systemweiten Problemen)
Ein Datenbank-Cluster fÃ¼r alle Services: weniger Wartungsaufwand, konsistenter Datenbankstand Ã¼ber komplettes Bestellsystem
Ein Datenbank-Cluster pro Microservice: bessere Isolation (Burst-Balance), Ã¼berschaubarere GrÃ¶Ãe bei Backups/Snapshots, individuelle Skalierung
Informationen sammeln bzgl. WartungsaufwÃ¤nden
Arbeitsorganisation im Betrieb berÃ¼cksichtigen: ein Team fÃ¼r ein DB-Cluster zustÃ¤ndig? Oder arbeiten mehrere Teams an einem DB-Cluster?
Last- und Performancetests hinsichtlich Datenskalierung auswerten
Datenmigration bei ggf. notwendigen Cluster-StrukturÃ¤nderungen berÃ¼cksichtigen!
: Wiedervorlage in PI 33

Agenda 22.03.2024

KlÃ¤rung, ob bestellsystem-parent-pom in der Form weiterbestehen sollte
Enge AbhÃ¤ngigkeiten fÃ¼hren zu manuellem Anpassungs- und Testaufwand
Zentrale Stelle zum Aktualisieren von AbhÃ¤ngigkeiten (z.B. fÃ¼r APIs und bei Schwachstellen)
Camunda in SV "bremst" Aktualisierung von bestellsystem-parent-pom
Vorschlag: PoC in einem IP-Sprint
Thema wird in CI/CD-Runde mit aufgenommen ( : in Agenda eintragen)
Aus Problem Solving: Versionsnummern von Releases noch nicht gut von Snapshots zu unterscheiden
Fragestellung: Was ist der Nutzen des Timestamps in der aktuellen Versionsnummer? Wird das irgendwo zwangslÃ¤ufig benÃ¶tigt?
Vorschlag:
Bei Trigger durch Git-Tag: Name des Tags
Bei Trigger auf Master-Branch: Basis-Versionsnummer gemÃ¤Ã POM + â-m-PIPELINE_ID-COMMIT-SHA-SHORTâ + â-SNAPSHOTâ
Bei Trigger auf Nicht-Master-Branch (z.B. "feat/"): Basis-Versionsnummer gemÃ¤Ã POM + â-b-PIPELINE_ID-COMMIT-SHA-SHORTâ + â-SNAPSHOTâ
Bei "-SNAPSHOT"-Suffix in den AbhÃ¤ngigkeiten kann Create-Release-Tag-Job abbrechen (PrÃ¼fung der AbhÃ¤ngigkeiten wÃ¤re einzubauen)
Weitere Frage:
Verwendung von Maven-Release-Plugin? Ggf. besser: Version-Plugin, da Release-Plugin auch Git-Operationen vorsieht; auÃerdem muss NPM-Projekt (Portal UI) berÃ¼cksichtigt werden
Separater Termin ( : einladen)
ACAT: Wir mÃ¼ssen wohl die ACAT Gruppen neu definieren...
Warum? Wir haben fÃ¼r das WRITING nur gmu Gruppen, welche einen Admin Account brauchen â separater Termin ( )
Betreibervorgaben werden nochmal geprÃ¼ft ( )
Martin/STeam: hat unser Keycloak eigentlich noch irgendwelche Verbindungen zu Nachbarsystemen (mit Systel-TLS-Zertifikaten)?
in der Vergangenheit benutzten wir den eBRS-AD, das ist lange deaktiviert, oder? â Systel-TLS-Zertifikate kÃ¶nnen entfernt werden
wir wÃ¼rden dann gerne unser keycloak-Login-Theme und das custom-CA-Cert-Setup aus dem Deployment entfernen, das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1018
erst nach Umstellung auf WebSSO in EVU-Testumgebungen umsetzen

Agenda 8.03.2024

DoD: Abnahme der Story in integrierter Umgebung vs. ADR 58
Entscheidung:
IEU Deployment in Testing-Pipeline aufnehmen (unabhÃ¤ngig vom E2E-Stand) â Abnahme kann weiterhin auf IEU stattfinden
erfolgreiches IEU-Deployment ist nicht notwendig fÃ¼r erfolgreichen Abschluss der Pipeline
Systemtests werden auf IEU nicht erneut ausgefÃ¼hrt bei Trigger durch Testing-Pipeline
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-7720150f306eO2CSYS-1020
AbhÃ¤ngigkeiten zwischen Projekten beim Deployment
zwischenzeitlich Ã¼ber manuelle Anpassung in bestellsystem-deployment.
LÃ¶sung Ã¼ber Multi-Artefakt-Projekte.
Neuer Enabler fÃ¼r STeam: PoC fÃ¼r Portal-UI + Portal-MiddlewareÂ 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-7720150f306eO2CSYS-1043
das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CBS-338
Aufgabenteilung zwischen Teams Zero und CIB
Ideen bzgl. API-UmsetzungÂ
Serialisierungsmechanismus (vor Deserialisierung auf Server-Seite bzw. nach Serialisierung auf Client-Seite Byte-Stream verwenden) erweitern (REST + Kafka); ggf. Ã¼ber Aspekte
Einheitlich konfigurierter ObjectMapper von Jackson
Ideen bzgl. Datenbank
Felder/EntitÃ¤ten Ã¼ber Annotations inkludieren/exkludieren
Relevante Felder konkatenieren und aus Ergebnis die Signatur erstellen; Reihenfolge der Felder muss beim Speichern der Metadaten zur Signatur berÃ¼cksichtigt werden â beim Auslesen wird in Metainformationen gespeicherte Reihenfolge zur Validierung gespeichert
Bei Assoziationen zu anderen Tabellen Grenze bei FremdschlÃ¼sseln ziehen (assoziierte EntitÃ¤t wird nicht signiert/validiert)
Konzept â ADR

Agenda 23.02.2024

klÃ¤ren, wie Kafka in den base-at-Umgebungen zukÃ¼nftig aufgesetzt wird
Â â Frage: Wer lÃ¶scht die Kafka-Topics in base-at ? (siehe Agenda 2.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-7720150f306eO2CSYS-977
Entscheidung: Variante 3 - eigene Kafka-Cluster pro Umgebung / Verwendung von MSK auf den statischen Umgebungen (IEU, SIT, ...)
Martin/STeam: wir hatten beim PI-Planning die Anregung mitgenommen den Workflow unserer Security-Scanner in der Pipeline zu Ã¼berarbeiten, das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-838
jetzt haben wir ein Enabler-Ticket mit vielen Gedanken aus dem PIP, aber seitdem keine Stakeholder die irgendwelche Anforderungen formulieren und konkretisieren
Frage hier in die Runde: was wollen wir Ã¤ndern?
Ticket in PI32 neu betrachten (nach weiteren Tests mit DefectDojo)
Entscheidung: Security-Scanner sollen per Default nur noch auf Master-Branch laufen
Folgende Security-Scanner nur in Master-Branch: Fortify, Whitesource, trivy, OWASP ZAP
neues Ticket fÃ¼r STeam in PI31Â 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-7720150f306eO2CSYS-987 anstelle von O2CSYS-838 (verschoben nach PI 32)
Martin/STeam: wollen wir auch fÃ¼r die Libraries und APIs die geplanten neuen Release-Prepare-Jobs Ã¼bernehmen? das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-896
bei Libraries natÃ¼rlich ohne Testing- und Staging-Pipelines und Deployment
passende Funktion die wir nutzen kÃ¶nnen: nur bei Git Tag Upload ins Prod-Repo, GitLab-Release mit Changelog, bei Bedarf auch Jira-LÃ¶sungsversion
Entscheidung: Kein akuter Handlungsbedarf. Neubetrachtung bei Diskussion Ã¼ber Refactoring von gemeinsam verwendeten JAR-Dateien/Bibliotheken
MSK Sizing
erste MaÃnahme: Speicherplatz erhÃ¶hen (30 GB), perspektivisch grÃ¶Ãeren Wert wÃ¤hlen als RDS
â Monitoring der Volumeauslastung prÃ¼fen
â Retention-Property prÃ¼fen
â Auto-Scaling-Konfiguration prÃ¼fen ( )
â Gehen Nachrichten beim Hochskalieren des Speichers verloren? ( )

Agenda 9.02.2024

DevOps: Synergien mit C2S mÃ¶glich und gewÃ¼nscht?
Vorstellung: Virtuelle ART-Ã¼bergreifende Teams zur Optimierung der Bereitschaftszeit in der BetriebsfÃ¼hrung
ART-Ã¼bergreifende fachliche BetriebsfÃ¼hrung sinnvoll
technische BetriebsfÃ¼hrung als ART-eigenes virtuelles Team
Michael/STeam: MultireplicafÃ¤higkeit von Bestellsystem-Service Stack in Namespaces bsz-ieu/bsz-sit/bsz-e2e etc. - Was wÃ¤re noch zu tun um alle mind. 2x auszufÃ¼hren?Â
Portal-Middleware in bsz-sit (Grund: BBZ + Metrik, BBZ soll durch NuR abgelÃ¶st werden, ggf. alternativ Metrik aus-/umbauen bzw. Test im system-integration-test deaktivieren)
taftap-tdm-konverter â noch in Entwicklung + nicht eingebunden in Tests â wird multireplicafÃ¤hig
e2e Namespace â kann hochskaliert werden
stammdaten-bereitstellung â Ticket fÃ¼r MultireplicafÃ¤higkeit: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-3391

Agenda 2.02.2024

KlÃ¤rung notwendig: Partnerkonfiguration im CI / TTK (Team-Zero)
Partnerkonfiguration in CI; keine erneute ZertifikatsprÃ¼fung in TTK
KlÃ¤rung mit KomBau, ob Zertifikate weitergeleitet werden mÃ¼ssen Â
Enabler zur Umstellung der Partnerkonfiguration von Yaml auf ein dauerhaft gut wartbares Konfigurationskonzept
Enabler zur PrÃ¼fung des kompletten Subjects (nicht nur CN)
Frage: Wer lÃ¶scht die Kafka-Topics in base-at ?
Muss Kafka-Server dafÃ¼r gestoppt werden? (https://stackoverflow.com/questions/33537950/how-can-i-delete-a-topic-in-apache-kafka/33538299#33538299)
prÃ¼ft bis zur nÃ¤chsten Architekturrunde, was zum LÃ¶schen von Topics notwendig ist (Standalone-Kafka + MSK)
Technische Dokumentation: Wo und Wie? (Team Zero)
Strukturiere Ablage von Dokumentation von Microservices + ggf. Betriebshandbuch Â
Martin/STeam: Benennung neuer Services
wir wÃ¼nschen uns dass unsere Services bzw. Komponenten prÃ¤fixfreie Namen bekommen. Weil wir besonders in den Helm-Charts viel mit Text-PrÃ¤fixen und Suffixen arbeiten, befÃ¼rchten wir sonst Kollisionen.
Ein kompletter Service-Name sollte nicht PrÃ¤fix eines anderen Service-Namens sein
und kÃ¶nnen wir uns im Bestellsystem auf eine Schreibweise von "konnektor" oder "connector" einigen? Anscheinend sind die ADR 57 (Kombau) Enablertickets da nicht einheitlich.
Beachtung einheitlicher Schreibweise
Git-Tags:
Format release-vX.Y.Z fÃ¼hrt zu Problemen in den Pipelines â Vorschlag: Versionsnummern ohne PrÃ¤fix verwenden X.Y.Z
Umsetzung ohne PrÃ¤fix; bei Problemen erneut betrachten
Bing/STeam: CNP-MSK bei Base-Umgebung: wollte mit Euch kurz diskutieren, ob CNP-MSK (oder Bestellsystem-Kafka) in Base-Umgebung insbesondere bei System-Tests verwendet werden soll.
Wunsch wÃ¤re CNP-MSK zu nutzen
AbhÃ¤ngigkeit zum Thema "LÃ¶schen von Topics" (siehe oben)
Besprechung in CI/CD-Runde Â

Agenda 19.01.2024

Dringend: Umgang mit Versandergebnis nach der Trennung CI / TTK
Entscheidung: Versandergebnis Ã¼ber eigenes Kafka-Topic von CI â TTK bzw. CI â KomBau
Daniel/CIB: Konzept zu KompatibilitÃ¤tstests https://git.tech.rz.db.de/bestellsystem1/docs/architektur/-/merge_requests/220 fÃ¼r das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-4746 vorstellen
ELK Stack (ELK Ã¤hnliches Stack) als KombauMock
stattdessen Kafka-Consumer in System Tests einbinden
EVU-Test-Umgebung: Nachrichten an KomBau verbleiben in Kafka-Topic; kÃ¶nnen mithilfe Kafka UI betrachtet werden
Camunda 8: Anforderungen an CNP (z.B. OpenSearch)
Security-Requirements-PrÃ¼fung: Annette, ggf. Diego, Jan, Bing+1, Frank oder Norbert

76 KiB Raw Blame History

Architekturrunde PathOS

ADRs in Arbeit

Agenda-Backlog

Agenda 10.4.2026

Agenda 6.3.2026

Agenda 6.2.2026

Agenda 1.12.2025

Agenda 17.11.2025

Agenda 17.10.2025

Agenda-Backlog

Agenda 19.09.2025

Agenda 05.09.2025

Agenda 08.08.2025

Agenda 25.07.2025

Agenda 27.06.2025

Agenda 13.06.2025

Agenda 26.05.2025

Agenda 16.05.2025

Agenda 28.04.2025

Agenda 23.04.2025

Agenda 04.04.2025

Agenda 07.03.2025

Agenda 21.02.2025

Martin/STeam: Im Kontext von Compliance und scm-info Ã¼berlegen wir wie wir mit archivierten GitLab-Projekten umgehen (O2CSYS-1521).

Agenda 07.02.2025

Agenda 27.01.2025

Agenda 29.11.2024

Agenda 15.11.2024

Agenda 01.11.2024

Agenda 11.10.2024

Agenda 27.09.2024

Agenda 06.09.2024

Agenda 09.08.2024

Agenda 12.07.2024

Agenda 17.05.2024

Agenda 19.04.2024

Agenda 8.04.2024

Agenda 22.03.2024

Agenda 8.03.2024

Agenda 23.02.2024

Agenda 9.02.2024

Agenda 2.02.2024

Agenda 19.01.2024

76 KiB

Raw Blame History