ankn/Orchestrator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
ba2bb8204cbda730b249bebd706168a8c9d4838c
Orchestrator/bahn/project-audit/data/confluence-export/pages/160729047_Archiv Achitekturrunde.md
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

102 KiB
Raw Blame History

Archiv Achitekturrunde

Confluence Page ID: 160729047 Version: 11 Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/Architekturrunde PathOS/Archiv Achitekturrunde Labels:

Alte Termine sind hier zu finden.

Agenda 15.12.2023

  • AT vs BASE-AT: Zusammenlegung sinnvoll?
  • Testkonzept zusammen mit Fred "überarbeiten" → Termin Anfang 2024  
  • DevOps → Workshops mit den Entwicklungsteam geplant   
  • Rolle von Team STeam
  • STeam enabled andere Teams; kein Betriebsteam
  • Themen sollen von den Entwicklungsteams übernommen werden
  • Bedeutung von SL Gold
  • Patch- und Schwachstellenmanagement: DefectDojo, Prozesse etc. → Workshop-Termin Anfang 2024  
  • Übersicht der Security-Requirements-Prüfung in Confluence übertragen:
  • Themenbezogener Termin Anfang 2024  

Agenda 01.12.2023

  • Keine Themen von Teams ZERO, STeam

Agenda 17.11.2023

  • Konsolidierung ADRs
  • in PI 31
  • Müssen wir Vier-Augen-Prinzip für unsere Git-Repos einführen? (https://db-planet.deutschebahn.com/pages/developer-experience/apps/blog/blog/view/ed513909-972a-444d-90f7-93b0d5808802)
  • Oder gilt das nicht für uns, da wir noch nicht produktiv sind?
  • Gilt aktuell nicht für uns, da nicht produktiv
  • Erneute Betrachtung vor Produktionsgang
  • Einführung hat Auswirkungen auf Hotfixes und Rufbereitschaft (DevOps)
  • Aktuell keine Notwendigkeit und kein Mehrwert → keine Umsetzung
  • Noch unabhängig vom neuen Release-Prozess würden wir im STeam gerne die aktuelle Build & Deployment-Pipeline kürzen, um weniger verwaiste 'running'-Pipelines zu hinterlassen, das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-777
  • Die master-Build-Pipeline wollen wir nach der SIT beenden. Also bis zur SIT sind alle Jobs wichtig und bestimmen den Status, nach der SIT ist Ende.
  • Alles nach der SIT (sit → e2e → evu-e2e&evu-test) bleibt übrig und müsste in eine neue oder temporäre Release-Pipeline
  • Meinungen? Anforderungen?
  • Verbesserung im Rahmen des neuen Deployment-Prozesses
  • Maven-Release-Plugin einführen und verwenden
  • Arbeiten mit SNAPSHOT-Versionen in der Entwicklung / feature-Branches
  • Bei Merge auf Master → MVN-Release-Plugin ausführen (release-prepare) → Ausführung von Release-Pipeline → release-perform
  • Start mit bestellsystem-parent-pom und APIs
  •  

Agenda 3.11.2023

Agenda 20.10.2023

  • RenovateBot verursacht viele Pipeline-Instanzen
  • Systemtests beschleunigen und stabilisieren → dadurch weniger offene MRs → weniger RenovateBot-Instanzen
  • Renovate-Config auf Limits prüfen (durch Limits können relevante Updates ausgelassen werden) und automatisches Rebase deaktivieren (sofern es keine Merge-Konflikte im MR gibt) 
  • Daniel zu "Smoketest-Job (bestellsystem-deployment) in CI/CD-Pipeline:  prüfen, ob weiterhin relevant" : Scheint durch helm install abgedeckt zu sein. Die Anfrage an static/datenschutz wie in https://git.tech.rz.db.de/bestellsystem1/infra/bestellsystem-deployment/-/jobs/159808152#L49 könnte auch als Kubernetes Probe aufgenommen werden, falls man sie behalten möchte.
  • Aufruf von static/datenschutz über Kubernetes Probe?  
  • generate_env_json → helm install?  
  • Vorschlag von Jan bzgl. Performance-Verbesserung der Pipelines: Systemtests in Master-Pipeline nicht mehr gegen IEU? 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-837
  • Berücksichtigung im Deployment-Prozess → Produktion  
  • Martin: Parallel laufende Systemtests auf IEU - Fehler? (ggf. nochmal diskutieren, falls IEU weiterhin für Systemtests verwendet wird / ggf. relevant für SIT)

Agenda 12.10.2023

  • Schwachstellenpatch für curl im kommenden Release notwendig (bis spätestens 25.10.)
  • Basis-Image wurde bereits aktualisiert
  • Alle Anwendungen müssen auf Basis des aktualisierten Basis-Images neu gebaut und für das kommende Release eingeplant werden
  • Supporting Tools werden wie folgt aktualisiert: 
  • EVU-Recorder: Team Zero
  • IFP-Mock, Preis-Mock: Team CIB
  • Rabattnummern-Bereitstellung: Team 404
  • Pipeline für Basis-Image-Aktualisierung (CNB Rebase) → STeam
  • Pipeline-Tools auch lokal nutzbar machen → STeam
  • Aktueller Stand bzgl. Thunder Client
  • Umstellung der Pipelines 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-835
  • Team 404 migriert auf Thunder Client lokal und passt anschließend die Pipelines für die Team 404 Apps an
  • Smoketest-Job (bestellsystem-deployment) in CI/CD-Pipeline: prüfen, ob weiterhin relevant ( )
  • Frank Lemke: Versionierung von TDM 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-253

Agenda 22.9.2023

  • Security-Anforderungen betrachtet
  • Ticket für Verbesserungen an den CI/CD-Pipelines in Team STeam: 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-753
  • Info zur Vorbereitung auf Termin am folgenden Montag

Agenda 8.9.2023

  • Postman-Nachfolger: Thunder Client vs. ReadyAPI
  • Wahl fällt auf Thunder Client
  • hoppscotch im Auge behalten (wird in Architekturgilde vertestet)
  • Team Zero: 8 Lizenzen
  • Team CIB: 9 Lizenzen
  • Team 404: 8 Lizenzen
  • Team STeam: 2 Lizenzen
  • Bestellvorgang der Lizenzen bei Volker starten
  • Team CIB: Wie können wir den Aufwand beim Hinzufügen neuer Konfigurationsparametern reduzieren? Momentan werden Werte in bestellsystem-deployment/values.yaml über bestellsystem-deployment-helm auf ein application.yaml im Container einer Anwendung abgebildet, mitunter nichttrivial. Nur Umgebungsvariablen a la Twelve-Factor-App https://12factor.net/config wäre ein Ansatz, siehe auch https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.external-config.typesafe-configuration-properties.relaxed-binding.environment-variables .
  • Hinweis von Martin: Grundsätzlich funktionieren in Spring Boot und auch bei uns Umgebungsvariablen. Sie überschreiben Werte aus der application.yml (nach dieser Präferenz-Hierarchie) und lassen sich als Block userenv in die values.yaml eintragen (Beispiel im Entwicklungshandbuch). Für umfangreiche Konfigurationen sind sie IMHO aber weniger lesbar als YAML. Mein Vorschlag: Umgebungsvariablen für Entwicklung und Test in Feature-Branches benutzen, und vor dem Merge dann ein Update im Helm-Chart um die Config "schön" zu machen.
  • Evaluierung von helmfile, inwieweit das beim beschriebenen Problem helfen kann
  • Wiederaufnahme der CI/CD-Runde
  • Diego: Können wir die CI/CD-Runde wieder aufnehmen? Wir haben die Termine-Reihe nicht mehr, aber sie ist nach wie vor nützlich, um spezifisch über Pipeline-, AWS- und CNP-Themen eingehen zu können.
  • Team CIB: hätten gerne wieder die CI/CD-Runde, um mehr informiert zu werden und darüber zu reden, wir mehr an den Pipelines machen können 
  • Klärung mit Bing
  • Team CIB: (wäre ein Thema für CI/CD-Runde) nicht normale Reihenfolge der Maven-Schritte in der Pipeline - maven clean install funktioniert in Steuerung-Vertrieb lokal nicht 
  • Analyse und Lösungsfindung für Steuerung-Vertrieb
  • Pipeline-Optimierungen
  • Konsequente Anwendung des Maven-Version-Namensschemas (Verwendung von -SNAPSHOT)
  • nicht erkennbar, ob SNAPSHOT oder Release-Version
  • maven release-plugin nicht anwendbar
  • Aktueller Diskussionsstand: API-Änderungen auf Feature-Branches vornehmen, Merge auf Master hat Release-Charakter
  • In folgenden Architekturrunden wieder aufgreifen

Agenda 25.8.2023

  • Architekturanpassung Steuerung-Vertrieb und Auftragsverwaltung-Trasse
  • Ergebnis der bisherigen Themenbearbeitung:
  • Daniel:
  • Lesende Abfragen von Dritten an AVT in drei Kategorien
  • Bestellsystem-intern: momentan nur Anfrage von BP an AVT
  • DB-intern: Zukünftig BI, ...?
  • EVU: Bis jetzt nicht, aber es kommt ObjectInfoMessage hinzu, Anfrage von SV an AVT, aber letztlich über CI vom EVU ausgelöst
  • 2.: Bereitstellung nur über Kafka durch SV wäre als Modifikation von Lösungsvorschlag 2a) oder 1) möglich
  • Was ist das Mengengerüst für 3.? (fehlt hier: )  Falls es extrem viele ObjectInfoMessage's sind, dann wäre Lösungsvorschlag 2a) ein Schritt in die falsche Richtung, Lösungsvorschlag 3 in die richtige
  • Variante 3 wurde beschlossen
  • ADR erstellen
  • BS-Enabler + Team-Enabler CIB/Zero
  • Probleme mit Loki (z.B. aufgeteilte Lognachrichten ab einer gewissen Nachrichtenlänge)
  • 16 KB werden teilweise schon durch lange Stack Traces erreicht
  • insbesondere relevant für Tests
  • SV: Map Diagnostic Context, Produktionsaufträge, Audit Logs für Kommunikation mit IFP
  • Team-Enabler CIB/Zero: Logging Optimierung
  • sollte Logging-Optimierung Problem nicht lösen/mindern, weitere Diskussion mit CNP nötig
  • AppSec Design Guidelines & Bestellsystem ( Termin für 1.9. einstellen) 
  • Guidelines: https://ass.gitpages.tech.rz.db.de/vorgaben/design-guideline-application-security/index.html
  • Erstanalyse Team CIB: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-4142
  • Information: neue Version vom openapi-Generator (v7)
  • Diego: Wie sollen wir die Migration aus Postman am Besten für nächsten PI einplanen? Postman Scratch-Pad wird bald deaktiviert und wir brauchen eine ADR für das nachfolgende Tool und auch entsprechende Pipeline-Anpassungen
  • Aktuelle offizielle Rückmeldung - 2 Alternativen:
  • Thunder Client (https://www.thunderclient.com/)
  • ReadyAPI, kann über Digitalportal bestellt werden (https://dbserviceportal.service-now.com/serviceportal?id=sc_cat_item&sys_id=3ea5b31d1baf49506125740f8b4bcb55)
  • Einbindung in CI/CD-Pipelines wäre zu klären (maßgeblich für Team 404)
  • Ergänzung: Die Smoketests für alle Pipelines verwenden auch Newman und müssen deshalb angepasst werden.
  • Evaluation der beiden Tools
  • Eine Pipeline mit Thunder-Client statt Newman wurde hier erprobt.
  • Daniel: Wer benutzt die Review Umgebungen? Man kann sie per DK8R_JOB_DISABLED: "true"  wie in https://git.tech.rz.db.de/bestellsystem1/apps/steuerung-vertrieb/-/merge_requests/1144/diffs deaktivieren und spätestens beim Starten einer Pipeline wieder aktivieren. Im Moment 44 Review-Umgebungen.
  • Global deaktivieren, bei Bedarf beim Starten der Pipeline aktivieren
  • Portal-UI benötigt Review Umgebung für cypress-Tests
  • Umsetzung mit Review durch STEAM

Agenda 9.8.2023

  • Daniel: Zu SV-AVT Thema 
  • Arbeitsstand ist, dass wir mit der Auflistung von Vor und Nachteilen der Lösungsvorschlägen noch nicht fertig sind
  • Die Systemtests sind keine reinen Blackbox-Tests, die dort überprüften Statuse erscheinen langfristig wichtig. Es ist aber noch zu klären, was hier die Anforderungen sind, z.B. bei einer Zusammenlegung von AV und SV müsste man sich überlegen, wie viel man von der auftragsverwaltung-Schnittstelle zurückbaut.
  • Fortify: alte Unterdrückte Fehlern sind wieder angezeigt als neue Fehlern
  • es gab auch andere neue Findings, die auf ein Update zurück zu führen sind
  • in Team CIB mehrere der neuen Findings unterdrückt, siehe https://git.tech.rz.db.de/bestellsystem1/apps/steuerung-vertrieb/-/blob/master/fortify_notes/dynamic-code-evaluation-jndi-reference-injection.txt für Dynamic Code Evaluation: JNDI Reference Injection
  • https://www.mend.io/blog/best-practices-for-dealing-with-log4j/ 
  • bei YAMLs von Umsystemen könnte man nachfragen, was die Lebensdauer von API Keys sind, wir unterdrücken Findings dazu
  • IAM NuR beantragt und provisioniert, warten auf Freischaltung, man braucht dafür DB Admin Cloud, brauchen weitere Account Freischaltung
  • soll für uns BBZ und Keycloak (Portal) ersetzen
  • Cognito aktuell nicht mehr geplant
  • können wir NuR für Camunda 8 benutzen?

Agenda 2.8.2023

  • Deployment auf E2E-Umgebung
  • Trigger bei neuen Tags: wofür aktuell verwendet?
  • vorübergehend deaktivieren, Auswirkungen beobachten
  • Upgrade auf neue PostgreSQL-Version
  • STeam-Ticket: 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-697
  • Hinderungsgründe?
  • keine Hinderungsgründe
  • auf den base-* Umgebungen können die Datenbanken gelöscht werden (wenn Migration problematisch)
  • AppSec Design Guidelines & Bestellsystem
  • Guidelines: https://ass.gitpages.tech.rz.db.de/vorgaben/design-guideline-application-security/index.html
  • Erstanalyse Team CIB: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-4142
  • von CICD Runde letzte Woche: Whitesource
  • Whitesource nur noch bis 1.4.2024; Umstellung auf anderes Produkt ab ~01/2024
  • https://db-planet.deutschebahn.com/pages/developer-experience/apps/blog/blog/view/9d8cf5be-ba53-4fc8-aa8c-4367f83682d3

Agenda 14.7.2023

  • ADR 53: Durch Anbindung von KomBau an CI neu zu bewerten
  • Termin mit Team Zero in KW29 vereinbaren
  • Diego: Die neue Seite für Commit-Nachrichten (https://git.tech.rz.db.de/bestellsystem1/docs/dokumentation/-/wikis/git#user-content-commit-nachrichten) empfehlt English als Commit-Sprache. Diese Frage wurde auch dem Architekten und dem PM zu Beginn des Projekts im Jahr 2020 gestellt und die damalige Antwort lautet, dass das Projekt auf Deutsch ist und deshalb müssen die Dokumentation einschließlich Commit-Nachrichten auf Deutsch verfasst werden. Hat es hier eine Änderung in der Meinung seitens Architekt bzw. PM gegeben und sollten wir jetzt lieber Englisch verwenden?
  • Satz wird aus Dokumentation entfernt; keine Änderungen an den bisherigen Vorgaben/am bisherigen Vorgehen
  • Spezielle Fachbegriffe sollten nicht frei ins Englische übersetzt werden

Agenda 6.7.2023

Agenda 16.06.2023

  • Unterdrücktes Fortify-Ergebnis in Auftragsverwaltung-Trasse: https://git.tech.rz.db.de/bestellsystem1/apps/auftrags-verwaltung-trasse/-/blob/master/fortify_notes/used_by_steuerung-vertrieb_only.txt
  • Feingranulares Berechtigungskonzept für REST-Schnittstellen notwendig
  • Authentifizierung von Microservices untereinander
  • Anforderungen klären und ART-Enabler schreiben
  • Tracing
  • offen: anwendungsübergreifendes Tracing funktioniert innerhalb von Bestellsystem noch nicht → Team Zero arbeitet daran
  • Klärung mit IFP bzgl. Correlation-Id über SQS (Einbeziehung von Frank Lemke); Thema Spring Boot 2.7 vs. 3 berücksichtigen
  • Klärung innerhalb vom Bestellsystem: was wird ins Tracing-Log geschrieben (muss/kann-Infos)?
  • Logging
  • Logging-Guidelines erstellen (im Rahmen der Architekturrunde)
  • Conventional Commits
  • Teamübergreifend auf eine Konvention einigen, diese dokumentieren und konsequent anwenden
  • JIRA-Ticketnummer muss enthalten sein
  • Erstellt Vorschlag für Konvention in Entwicklerhandbuch

Agenda 02.06.2023

  • Namensgebung für neue E2E-Umgebung. Klare Trennung zwischen EVU-E2E-Testumgebung und E2E-Umgebung
  • Patch- und Schwachstellenmanagement
  • Proaktives Patchmanagement (O2CSYS-326)
  • teilautomatisiert: Renovate-Bot
  • manuell: Infrastruktur
  • Apache Kafka?
  • Anfrage von IFP
  • Fragen:
  • Wer hostet und wartet Kafka?
  • Gibt es einen Managed Service? → AWS; CNP-Support wird benötigt

Agenda 25.05.2023

  • Release-Management:
  • Abwärtskompatibilität zwischen HEAD von Master/Main und Produktionsstand (insbesondere in Bezug auf DB und APIs)
  • Problemstellung: DM-JSON in DB Blob gespeichert
  • Bisherige Diskussion:
  • Aktuelle Lösungsidee:
  • In der AV Datenbank sind verschiedene Versionen der TDM-Nachrichten gespeichert (Versionsnummer muss gespeichert werden → separates Feld oder im Payload)
  • AV bietet in der API die aktuellste, mit den anderen Komponenten abgestimmte Version an
  • AV beinhaltet Mapper, die die verschiedenen Versionen in der Datenbank auf die in der API benötigte Version übertragen
  • Änderungen am TDM sollten möglichst abwärtskompatibel stattfinden; zusätzlicher Mapper oder Anpassung an bestehenden Mappern wird bei inkompatiblen Änderungen (z.B. neues Pflichtfeld) notwendig
  • Bei inkompatiblen Änderungen wird fachlicher Input benötigt, wie die alten Daten darauf gemappt werden können (z.B. wie ist ein neues Pflichtfeld zu befüllen, das in alten Nachrichten nicht enthalten ist?)
  • Migration alter Nachrichten in der AV Datenbank valide?
  • Migration kann on-the-fly passieren (parallel zum Abruf über die API werden die Daten in der DB angepasst)
  • Batch-Job (z.B. sehr alte Versionen migrieren und danach die alten Mapper ausbauen)
  • SIT + E2E vs. ITU bei IFP
  • Semantic Versioning auf App-Ebene: Conventional Commits + semantic-release (https://github.com/semantic-release/semantic-release)?
  • O2C-435
  • Postman: Scratch-Pads werden abgeschafft (https://blog.postman.com/announcing-new-lightweight-postman-api-client/)
  • Alternative zum Type-mapping: In der YAML type: number, format: Bigdecimal. Das liefert java.math.BigDecimal .

Agenda 08.05.2023

Agenda 06.04.2023

Ergänzung api-parent-pom um TypeMapping: xmlDouble=java.math.BigDecimal]]> => Umsetzung ok, bilateral zwischen Provider- und Konsumentenanwendung abstimmen

  • CNP DB-Migration
  • welche Datenbanken werden migriert, welche neu angelegt (IEU vs E2E)
  • Migration auf IEU (Übung für EVU), SIT, EVU-Test, EVU-E2E
  • Info von System-Team über Migrationsdauer (Wartungsfenster)
  • LUP Löschen & Neuaufbau
  • Umstellung soll bis 29.05. passieren
  • Signale auf IEU z.B. von Systemtests und Vorführungen auf IEU
  • Signal einschränken sehr aufwändig
  • / / Detailbetrachtung
  • Wie kann man die Anzahl der Git-Repos reduzieren?
  •  
  • Vermeidung von nicht-kompatiblen Schnittstellenänderungen
  • TAF/TAP-Schnittstellen
  • BS-interne APIs
  • Umsysteme (IFP, neXt usw.) → In C2S-Architekturrunde ansprechen

Agenda 24.03.2023

  • Spring Framework: High severity vulnerabilities CVE-2023-20860, CVE-2023-20861
  • Upgrade auf Versionen 2.7.10 bzw. 3.0.5
  • Offene Fragestellung bzgl. Patch- und Schwachstellenmanagement:
  • 48h Frist zur Behandlung der Schwachstellen beginnt "mit der Veröffentlichung der Schwachstelle (z.B. als CVE oder eines vergleichbaren Industriestandards)."
  • https://cve.report/CVE-2023-20860, https://cve.report/CVE-2023-20861 im Status "Not Yet Published" → laufen die 48h schon?
  • Tools in den Build-Container-Images auf Aktualität/Schwachstellen prüfen
  • Liste von problematischen Abhängigkeiten/Tools

Agenda 10.03.2023

  • Dringende Themen:
  • Fehler in den Pipelines aufgrund von Finding in trivy
  • Deployment auf IEU ok
  • kein Deployment auf E2E/EVU, bis Problem gefixed
  • ADR 53 (Hybride Anbindung der Eingangskanäle an Backend-Systeme) zur Ablösung von ADR 32: https://git.tech.rz.db.de/bestellsystem1/docs/architektur/-/blob/master/03-adrs/0053-kanal-anbindung-an-backend.adoc
  • Patch- und Schwachstellenmanagement
  • Pipelines blockieren bei kritischen und hohen Schwachstellen. Zu klären ist das Tracking von mittleren und niedrigen Schwachstellen.
  • Tracking von PEN-Test-Findings
  • Zielgerichtete Konfiguration von Codescannern (e.g. Poor Naming ausklammern)
  • Tickets an CNP-Support werden nicht bearbeitet oder liegen lange. Fester Ansprechpartner von CNP?

368 complete hält Rücksprache mit Volker Grabowski und Christian Seltsam

  • Christian Seltsam hat das Thema bereits bei CNP angesprochen; fester Ansprechpartner ist aktuell nicht vorgesehen
  • Problem wird weiterhin adressiert

Agenda 24.02.2023

  • Dringende Themen
  • in letzter Zeit viele fehlschlagende Pipelines
  • Artifactory-Verbindungsprobleme
  • keine Nodes verfügbar (fehlende CPU/RAM-Kapazitäten)
  • mit Christian Seltsam abstimmen
  • Norbert:
  • Spring Boot 3: T0 hat nur CI zu erledigen. (KB, SB, AV, ER + zuhörige Apis sind schon umgestellt, Api-s habe SB2 und SB3 Versionen parallel, wo nötig)
  • Abhängigkeit zu javax/jakarta-Paketen in den APIs
  • Spring Boot 2 → 3: Wechsel von javax zu jakarta Paketen → Inkompatibilität zwischen Versionen
  • Spring Boot 3 Variante der APIs in separatem Branch (bis alle Apps auf Spring Boot 3 umgestellt haben)
  • Spring Boot 3 + Camunda:  7.19+Workaround Config oder warten bis 7.20? (7.19-alpha3 war am 14.2.2023 veröffentlicht → 7.20 dauert zu lang)
  • Config Workaround mit 7.19 stable testen, falls nicht erfolgreich warten auf 7.20
  • Spring Boot 3+ ST/SIT/Lup: macht es sinn es vor der ganze Umstellung (auch PMW, SV) zu machen? Ich denke nicht.
  • Architekturthemen für PI: schon Antwort von PO-s?
  • Release-Script Anpassung wegen Semantik Versioning. Problem mit derzeitige Script: letzte Version war 1.1.0 mit 1.2.0-SNAPSHOT in pom.xml. Möchte ein Release mit Bugfix machen, neue Version 1.2.1 als Parameter --> Erzeugte Tag + Release 1.2.0.  Laut Sem.Ver. sollte es eigentlich der 1.1.1 sein.  Lösungsmöglichkeiten:
  • Tag in Script is von Parameter gemacht und nicht automatisch generiert. (release.sh -v 0.4.2 -t 0.4.2 -a apps/logging-utils)
  • Versionnummer in Param ist der Tag. neue Version in pom.xml ist Tag-SNAPSHOT. 

Agenda 10.02.2023

356 complete probiert Extension aus

365 complete Issue wird in zukünftiger OpenLens-Version behoben (siehe https://github.com/lensapp/lens/issues/6823, miskun 4 Januar)

366 complete bis dahin, alte Version weiterbenutzen

  • Follow-up "Bing: ADR 32?" / Koppelung von CI und SV durch Benutzung der gleichen API

357 complete schreibt Email an Bing und befasst sich damit, falls Bing Montag nicht wieder da ist (d.h. dediziertes Meeting)

361 complete Abstimmungsmeeting am 1.3.

  • Wurde/Wird logging-utils genutzt und weiterentwickelt? Wenn ja, kann/soll SV auch nutzen?
  • Benutzt in CI, KDA, SB: ja,  Weiterentwicklung: wenn etwas gebraucht ist, ja, aber seit Sommer 2022 gibt's keine neue Anforderungen

358 complete nimmt es zu Team CIB, weil darüber Tracing laufen soll

362 complete Enabler Ticket (das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-2855)

  • haben über Semantic Versioning geredet

Agenda 27.1.2023

  • Dringende Themen

  • Norbert:

  • PAN-Client: nötig/nicht nötig, Schon genehmigt/konfiguriert?

  • immer noch nicht 100% klar, ob nötig ist, aber alle bestellen

  • in Team Zero auf https://pan-webportal.secure-admin.db.de/ noch nicht genehmigt, andere noch nicht bis dahin gekommen

  • Spike Stories wegen Trace in mehrere Teams

  • zwei unterschiedliche Lösungen vermeiden/mehrfache Nachforschungen vermeiden

  • nur in Team Zero Story: O2CZERO-1396

  • Semantic Versioning + Release / Sprint - wie soll der Version aussehen ?  Es ist kein Große Änderung, kein Interface Änderung, kein Neu Entwicklung und oft auch kein neu Bugfix. In einige Projekten nur Bibliothek/helm aktualizierung. Gleichzeitig ist ein Gute Punkt zu 'speichern' Beste Idee: Trotz alles als Bugfix zu handeln, so 0.1.1 → 0.1.2.

  • ja

  • "Lösungsversion(en)" oder anderweitig in Jira zur Planung, POs?

  • Entscheidung wegen der TrassenAnmeldung/VersandAuftrag (ADR 32?). Derzeit der beste wäre ein Job in CI dass der Polling macht.

  • Daniel: Bing meinte, Meeting dazu ca. 2 Sprints vor PI-Ende,  tendenziell Thema für das nächste PI (Vorschlag von Volker)

  • Vorbereitung dafür in diesem PI inkl. Enabler mit definierter Lösung schreiben

  • Onboarding noch schwieriger mit PAN-Client?, sowieso schon schwierig, insbesondere bei Externen VPN-Zugang schwieriger je nach Beantragungsweg

351 complete   nimmt es zu Team SOS mit, Frank Lemke als Externen fragen

  • logging-utils:

352 complete bestellsystem-parent-pom als Abhängigkeit entfernen, ...

Agenda 13.1.2023 (?)

  • Dringende Themen

  • Datenbank für den neuen Service Rabattnummern Bereitstellung in allen Umgebungen bereitstellen → Vorgehen kurz geklärt.

  • Daniel: Umgang mit OutOfMemoryError ( O2CCIB-1960 ) ist m.E. hinfällig, weil (vom Systemteam?) -XX:+ExitOnOutOfMemoryError als Java-Option hinzugefügt wurde und wir beobachten, dass Steuerung-Vertrieb beendet wird. 12 factor app (oder 15)

  • Wunsch ist, dass die Anwendung beendet wird. Aktuell scheint das Verhalten auch so zu sein. Ticket wird geschlossen. Bitte bei vermehrten Restart der Container bitte Ursache klären.

  • Daniel: Gleichsetzung von Schnittstellen-Version und Version des Maven-Artefakts mittels "@project.version@"

  • Beispiel an externer Schnittstelle:

  • Wenn man die Tags der Vertriebsaufträge-Schnittstelle https://git.tech.rz.db.de/bestellsystem1/apis/vertriebsauftraege/-/tags anschaut, dann gibt es z.B. Tag 3.1.1, welcher soweit ich erkennen kann, nur Bestellsystem-internes verändert hat.

  • Der Konsument ist auf Version 3.1.0, was ok ist (auch wenn 3.1.1 tatsächlich ein Bugfix an den Yaml's wäre), aber zu Verwirrung führen kann/Unklarheit, ob vergessen wurde, die Konsumenten zu informieren/ob sie informiert werden sollten.

  • Beispiel an interner Schnittstelle:

  • Bei der Trassenanmeldung-Schnittstelle waren eine Zeit lang ...v3 und ...v6 Java-Packages im Jar enthalten.

  • Habe in https://git.tech.rz.db.de/bestellsystem1/apis/trassenanmeldung/-/tags/6.3.0 alles was mit den v3 Packages zu tun hat entfernt und bin von 6.2.0 auf 6.3.0.

  • Kann man sich mit besagter Gleichsetzung in so einem Fall überhaupt an Semantic Versioning halten ohne v7 einzuführen? 

  • Wie können wir den Build der Klassen auf andere Weise cachen und nur die yaml's in die publizierte Version einfließen lassen ?

  • ADR 37 https://git.tech.rz.db.de/bestellsystem1/docs/architektur/-/blob/master/03-adrs/0037-api-publication.adoc , "[...] Diese Entscheidung wird zunächst noch aufgeschoben."

  • Entscheidung konnte nicht getroffen werden. Trennung von Externen und Internen Konsumenten sollte berücksichtigt werden. Daniel stellt einen Termin dazu ein.

  • Norbert: Zipkin statt otlp in Tracing wegen automatische TraceId/SpanId in Logs  vs Logs sollen alle in TALOCatalog per hand geloggt werden mit "withDetail("traceId", traceId)"

  • Es ist auszuprobieren. Zero hat noch keine Lösung mit Telemetrie gefunden. Termin Norbert / Frank L. /Frank T. zur Klärung des weiteren Vorgehens.

  • Bing: ADR 32

  • Koppelung von CI und SV durch Benutzung der gleichen API

  • Sollten wir Push Interfaces vermeiden?

  • Sollten wir Queue-Mechanismen integrieren? Message Broker benutzen?

Besprechung 16.12.2022

Wegen DevOps-Workshop und Jahreszeit gab es einen allgemeinen Austausch. Themen waren

  • aktuelles Security-Finding in org.apache.cxf:cxf-core -> erfordert WhiteSource- und Trivy-Ausnahme bis zum Update
  • aktuelle Probleme in 'automatic tests' von portal-middleware
  • PostgreSQL-Verbindungen mit Spring Boot/Hikari Pool Size 10
  • Architekturblick auf unsere Komponenten, Nachbarsysteme, und erwarteten Service Levels
  • Security-Anforderungen aus Konzern-Richtlinien sowie abgeleitete Entwickler- und Betreibervorgaben (Übersicht im Systel DevSecOps Wiki)
  • Gespräch zu K8s-Namespaces (O2C-434)
  • Monitoring/Tracing
  • aktuelle Limits bei Grafana-Metriken (O2CSYS-514)
  • Push-API für Metriken: ist bisher nicht vorhanden, will CNP im PI anbieten, soll künftig für LuP benutzt werden
  • Wenn Tracing von Spring Boot 3 Bibliotheken übernommen wird, dann sollte der Agent deaktiviert werden. Dazu sind dann im Helm-Chart die Umgebungsvariablen hinter Parameter tracing: enabled  zu refactoren.
  • im DB API-Portal sind wir mit verschiedenen Namen vertreten (Bestellsystem, Neues Bestellsystem, Bestellsystem-Zugfahrt), das könnte in Zukunft aufgeräumt werden

Agenda 02.12.2022

  • Martin/Bernd: Staging-Reihenfolge und Einordnung der LUPs
  • T0:

342 complete Architektur Dokumenten landen in Confluence nicht.     Generierung in Git Lab funktioniert. Automatische Übertragung nach Confluence ??? Michael Fragt bei Konstantin nach wie das gemacht wird.

                                        Lösung: Die Pipeline baut immer beides, HTML und PDF. Das findet man hier: https://bestellsystem1.gitpages.tech.rz.db.de/docs/architektur/index.html                                         dh. bei jeder Änderung entsteht eine neue PDF-Version. 

  • Lup Umgebung Trennungen per Team
  • Norbert: Api-Parent-pom Projekt in Git
  • Semantic Versioning in den Teams:
  • Info: Pipeship erstellt 4 stellige Versionen (+ Suffix "-$TIMESTAMP-$HASH"), was grundlegend OK ist, sofern die ersten 3 dem Semantik Versioning entsprechen 4 Stellen kommen daher, weil Pipeship unseren 3 Stellen des Git Tags eine hinzufügt Details: ${gitTag}.${commitsSinceLastTag}-${timestamp}-${shortCommitHash}
  • Talo logged bereits Versionsnummer (basierend auf POM Info) – aber noch "-SNAPSHOT"
  • Tasks

346 incomplete Task: Talo Logging überall → Teams

  • Braucht Enabler

347 complete Task: POM Version Job überall (alle Apps) → System Team

  • Enabler das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-540

348 incomplete Task: Teams müssen Taggen mit 3 Stellen, mit Semantik Versioning als Basis → Teams

  • Braucht Prozess, also keinen direkten Enabler

Agenda 18.11.2022

340 complete überlegt wegen zyklischer Abhängigkeit zwischen CI und SV 

  • Alte todos durchgehen

Agenda 4.11.2022

  • Dringende Themen
  • Martin/Bing: ADR 51 zum bep-mock (vom 21.9.) wird jetzt geschrieben. Bitte gegenlesen und ergänzen, damit wir den bald beschließen können. wurde abgeschlossen.  https://git.tech.rz.db.de/bestellsystem1/apps/bep-mock
  • Michael RR bittet aus jedem Team eine Person ihn beim Einrichten der Entwicklungsumgebung zu unterstützen.
  • : ADR 03 fertigstellt. Bitte um Review.

Agenda 21.10.2022

Teilnehmer: Michael, Konstantin, Annette, Dominik, Frank, Alexander, Martin, Norbert

  • Vorstellungsrunde
  • Dringende Themen
  • Michael: Apache-Schwachstelle => Status ist grün.
  • Annette: Wiremock ist betroffen und im Deployment von Portal-Middleware drin.
334
complete
Termin mit Michael RR organisieren, Enabler anlegen, um Wiremock aus dem Sourcecode zu entfernen.
  • Martin: Team CIB muss noch das Wiremock-Image im BEP-Mock aktualisieren.
  • CNP hat den Standpunkt, dass ALLE Anwendungen in der EVU-Test Umgebung wie Internet-exponiert zu behandeln sind, auch wenn sie selbst keine APIs über ISGW exponieren.
  • Alte Todos durchgehen
  • Norbert:
  • Wer kann in CI mit der "Mehrere Versionen von Request an eine Endpunkt" unterstützen? => Umsetzung basierend auf dem aktuellen Stand beginnen (keine explizite Erfahrung im Team CIB).
  • Jira Nummern in Commits (bei CIB und Zero sind sie drin, aber in 404 nicht) wegen ChangeLog.

335 complete : im Team 404 absprechen und einführen.

336 complete : ADR 03 fertigstellen.

  • Trivy Fehler von (Priorität: hoch, bei uns durch springboot-webflux angezogen): Altenativen
  • DependencyManagement in Parent-pom
  • Warten bis neue Spring-Boot kommt (bis dahin eine Ausnahme)
  • Dependencies in Api-s ändern (z.B. OpenApi, WebFlux reicht während Bauzeit, muss nicht in die generierte Jar unbedingt drin sein
  • Todo

338 complete erkundigt sich bei CNP nach deren Einordnung

Agenda 7.10.2022

Teilnehmer: Annette, Bernd, Bing, Dominik, Frank L., Jasmin, Oliver, Martin, Konstantin

  • Dringende Themen
  • CNP Grafana-Update/-Umzug war erfolgreich, uns fehlen aber noch Metriken aus dem Dev-Cluster, vgl. das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-501
  • Martin: kurze Vorstellung Tracing-Konzept
  • Bing: Umgang mit trivy-Findings bei Images ohne verfügbare Updates?
  • technische Optionen
  • .trivyignore (+Bug-Ticket in Jira)
  • GitLab-Job mit allow_failure  (+Bug-Ticket in Jira)
  • Security-Beauftragter?
  • Konstantin: bald kommt der neue Architekt für das Bestellsystem

Agenda 21.09.2022

Teilnehmer: Khalid, Frank T., Alex P., Bing, Martin, Dominik, Konstantin

  • Dringende Themen
  • Martin/Bing: Fragen zum neuen BEP-Mock. 
  • Konstantin: Das Thema PACT (CDC-Testing) wird nicht fertig. Soll aber dokumentiert werden.

325 complete : Termin mit Bing zwecks Dokumentation des bisherigen Standes.

  • Diego (heute abwesend): Brauchen wir SSL für die Lokal-Entwicklung? Fortify zeigt einen Fehler, weil wir HTTP als Protokoll für die UI erlauben und wir machen das, weil HTTP lokal verwendet wird und auf dem Server stellt unsere Infrastruktur fest, dass wir nur HTTPS anbieten.
  • scheint kein dringendes Thema zu sein. Kann 404-intern entschieden werden.
  • Martin/Bing: Fragen zum neuen BEP-Mock. BEP-Mock
  • Inhaltlich wird der sehr leichtgewichtig sein, das heißt für's erste ein Wiremock-Image + 4-10 Config-Dateien um das statische Mapping zu bestimmen.
  • Frage 1: wie bauen wir ein Container-Image?
  • pipeship product deploy_k8s_openshift – das "große Setup" mit allen Teststufen, genau so wie für unsere Anwendungen (so wie in SV, ifp-mock, etc.)
  • Vorteil: gleicher Workflow wie für andere Komponenten
  • Nachteil: erscheint sehr schwergewichtig, selbst wenn wir vieles deaktivieren (SonarQube, Fortify, etc.)
  • pipeship product release_oci_image – kleinere Pipeline, nur zum Container-Image bauen (z.Bsp. im infra/conventional-changelog-builder)
  • Vorteil: kleinere Pipeline, trotzdem versionierte Images als Build-Artefakte
  • ohne eigenes Image – wir benutzen nur ein Helm-Chart um das Wiremock-Image zu starten und irgendwie (per initContainer) eine eigene stub-Config reinzuschreiben (so wie mit Locastack)
  • Vorteil: kein eigenes Image
  • Nachteil: Versionsstand der Stubs ist nur implizit im Helm-Chart (und z.Bsp. in System-Test nicht sichtbar)
  • Frage 2: wie starten wir das Container-Image?
  • als eigenen Service, also so wie SV, ifp-mock, etc.
  • Vorteil: mehr Möglichkeiten falls wir künftig mehr Config oder mehr State brauchen
  • als Sidecar-Container zu SV
  • Vorteil: kein neuer Service notwendig
  • Nachteil: "haben wir noch nie so gemacht", d.h. wir müssen erstmal im Helm-Chart ermöglichen einen Sidecar zu konfigurieren
  • Auswahl der Alternativen oben in Fett:

326 complete : als ADR erfassen inkl. der Entscheidung, ob ein Mock für alle Nachbarsysteme des SV. → https://git.tech.rz.db.de/bestellsystem1/docs/architektur/-/merge_requests/48

  • Konstantin: Als Alternative zum Microsite Master würde ich gerne auf diese Asciidoctor-only Variante wechseln: Ergebnis

327 complete : Merge in den Master + Info in Teams

  • Konstantin: ausstehende Übergaben - welche Architekturthemen sind noch abzuschließen/nachzudokumentieren.

328 complete : die Tabelle oben (offene ADRs) durchgehen und einarbeiten => danach löschen.

329 complete : ADR-Liste in Arch-Beschreibung als Tabelle überarbeiten (ID, Zusammenfassung, Status, Team-Scope)

330 complete : ADR für Rahmenvertrag-Attachments anlegen (Konstantin erstellt einen Rumpf => hier) - 10.02.2023: Bis jetzt nicht fachlich geklärt, ob Bedarf vorhanden

Agenda 09.09.2022

  • Dringende Themen
  • CNP scheint in einer Umstrukturierung zu stecken, was die Reaktionszeiten und das Vorantreiben Betriebskritischer Themen, wie Verschlüsselung und Autorisierung aktuell blockiert.
  • Daniel: Grafana-UX-Problem (springender Cursor) => wird laut CNP durch ein Grafana-Update behoben, aber wann?
  • Daniel: Zyklische Abhängigkeit zwischen CI und SV ist "unschön". Warum wurde es so gemacht? Siehe ADRs 20 und 32. => Rückfragen bei Bedarf auch in einem Übergabe-Termin o.ä.
  • Konstantin: Es wird aktuell vom Team VISTA eine Trivy-Nachfolge ausgeschrieben. Eine Einführung ist frühestens in 12 Monaten geplant.
  • Konstantin: Stand Whitesource-Konfiguration, s. das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-458

317 complete : MRs für Apps und APIs stellen.

318 complete : Umstellung auf Microsite-Master abschließen (Bilder fixen etc.)

  • Konstantin: Stand Versionierungskonzept =>https://bestellsystem1.gitpages.tech.rz.db.de/docs/architektur/05_Konzepte/04_api-versioning.html
  • => Team Zero (Norbert) hat zu einem Termin nächste Woche eingeladen, um das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-785 abzuschließen. 
  • Daniel: Team CIB hat im IP-Sprint einen Bug, der prinzipiell auch Versionierung erfordern würde. das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-1927

Agenda 30.8.2022 (statt 26.8)

  • Dringende Themen
  • Konstantin: Grafana-Stabilität? => Es ist weiterhin langsam im Bereich Log-Auswertung. Die Metriken sehen schon besser aus.
  • Norbert: Talo-Logging ja oder nein? => Talo ist Vorgabe, u.a. von CNP.
  • Eine Abweichung ist schwierig aber theoretisch möglich solange man die Daten im selben Format loggt.
  • Talo4 wird prinzipiell weiter entwickelt, auch wenn es kein dediziertes KOLT-Team mehr gibt. 
  • Norbert: häufige Fortify-Findings => beheben oder False-Positives eintragen. Beispiel: unbounded für Element-Anzahl in XSD. => dies ist ein echtes Problem (wegen möglicher "XML-Bomben").

311 complete : bitte im PO/PM Sync klären, ob wir (zusammen mit IFP?) in TDM sinnvolle Grenzwerte definieren können.

  • Daniel: Umgang mit Exceptions ist zu "robust" indem auch schwerwiegende Fehler wie OutOfMemory abgefangen werden.

312 complete : analysieren und Enabler für IP-Sprint erstellen. => das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-1960

313 complete : JVM-Metriken müssen analysiert und die Requested-Ressourcen angepasst werden. Das muss in jedem Team erfolgen. Ein ART-Enabler kann für PI 26+ eingeplant werden (im alten Jira suchen). => das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-333

  • Konstantin: Microsite-Master vorführen
  • Einigkeit, die Architektur-Doku als Microsite fortzuführen. Das Entwicklerhandbuch bleibt weiterhin im Wiki.
  • Die Historie der beiden Git-Repos zu erhalten ist schwierig.

314 complete : probiert, ob man zwei Git-Repos mergen kann. → git pull --allow-unrelated-histories ../dokumentation (im architektur repo)  MR: https://git.tech.rz.db.de/bestellsystem1/docs/architektur/-/merge_requests/25

Agenda 15.8.2022 (statt 12.8)

  • Dringende Themen
  • Martin/Diego: OWASP Scanner zu langsam. Können wir diesen seltener durchführen?
  • Die Vorgabe ist: wöchentlich. Daher nächtlich wäre z.B. ok. Weitere Ideen, wie Umsetzung analog zu Systemtests => Tester JF bzw. CI/CD Runde.
  • Konstantin: der nächste Termin wird voraussichtlich auf Dienstag die Woche drauf verschoben.

303 complete  : Termin verschieben

  • Konstantin: Neubesetzung der Architektenrolle im September geplant. => Vorschläge willkommen.
  • Konstantin: Architekturdokumentation
  •  Aktualisierung auf den Stand von Pi 25 soweit erfolgt. 
  • Siehe insb. Kapitel 8 - querschnittliche Konzepte.
  • Auch das Glossar wurde erstmalig befüllt.
  • Potentieller Wechsel der Architektur-Doku auf Microsite-Master.
  • Als etwas schlankere Alternative gibt es inzwischen BCM-Techdoc.
  • Nächste Schritte:
  • Querschnittliche Konzepte durchgehen und ggfls. aktualisieren.

304 complete : 8.3.1. Benutzeroberfläche => neuen Link für die UI-Spez: Der Link bleibt gleich () aber ich habe den Inhalt angepasst und einen Link zu dem letzten Zustand in Figma hinzugefügt.

  • Aufräumen der ADRs und Konzepte => idealerweise alle Branches gemergt oder gelöscht werden.
  • Konstantin: Konzept Redesign der EVU-Stammdaten-API besprechen.

306 complete : Termin mit Team Zero organisieren.

  • Norbert: Team Zero designt gerade die LuP-Tests neu. Hier muss die Einbindung der echten AWS-Dienste berücksichtigt werden.
  • : Im Team ansprechen, hier das Ticket

Agenda 29.7.2022

Das komplette System-Team ist in einem Paralleltermin.

Agenda 15.7.2022

  • Dringende Themen
  • Konstantin: Ein Blick auf Whitesource.
  • Diego: Whitesource braucht häufig mehrere Tage, um Lizenzen für neue Bibliothek-Versionen einzupflegen. Das führt zu ständigen Pipeline-Abbrüchen, insb. im NPM-Bereich.
  • Beschluss: wir deaktivieren die Policy "Systel-Unknown", d.h. für unbekannte Lizenzen schlägt die Pipeline nicht fehl.
  • Es bleibt die Frage nach dem Umgang mit den Lizenzen in der Kategorie "Review Required".

297 incomplete Das soll zunächst von Teams dezentral geprüft werden.

  • Daniel: Wie ist die Entscheidung bzgl. der Löschung von Development-Branches und -Umgebungen zu verstehen?
  • Deployment bleibt, solange nicht alle Teams ihre Development-Branches abgeschafft haben. (vgl. das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C404-1162).
  • Perspektivisch soll in Bestellsystem-Deployment nach Bedarf eine neue Umgebung angelegt werden (als Vorlage idealerweise die IEU nehmen).
  • Norbert: bisherige Erfahrungen mit Springboot-WebFlux-WebClient in CoP ? ja / nein ?
  • => sehr gerne. Norbert geht auf Edmond zu.
  • Team CIB hat ebenfalls an einigen Stellen inzwischen WebFlux im Einsatz.
  • Falls unser Gesamteindruck positiv ist, planen wir für PI 26 einen ART-Enabler für den Umstieg auf WebFlux ein.
  • Konstantin: Pläne bzgl. CDC-PoC mit Pact.

298 complete Bing und Konstantin bereiten eine Übersicht für den nächsten (oder übernächsten) Termin vor.

Agenda 1.7.2022

  • Dringende Themen
  • Diego: Wenn wir Git Workflow einsetzen. Sollen wir dann den development  Branch löschen (nicht die Umgebung).
  • ja, aber bitte die Abhängigkeiten in bestellsystem-deployment  beachten. Kommt dazu auf Martin zu.

293 complete legt einen Enabler an das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C404-1162

  • Alle wichtigen Infos und Links bitte hier dokumentieren.
  • Das Zielbild ist künftig auf die Development-Branches zu verzichten.
  • Rollen in Gitlab noch nicht einheitlich verwendet.

294 complete : in Onboarding klarstellen

  • Alte Todos durchgehen
  • Konstantin: Architektur-Doku wird gerade aktualisiert. Der neuste Stand ist hier zu finden.
  • Eine allgemeine Bitte: Auffälligkeiten oder Mängel in der Beschreibung im Architektur-Kanal melden.
  • Konstantin: eine Neue API wurde ohne (explizite) Rücksprache mit der Architektur eingeführt. Dies sollten wir künftig vermeiden, um Umbau-Aufwände zu reduzieren. Außerdem ist hier der Use Case zu diskutieren (Speichern der Daten in einem externen Format).
  • Im PI 25 sind keine (ganz) neuen Schnittstellen geplant, aber  es werden durch Zusammenlegen neue entstehen.
  • Die Schnittstellen sollen nach Möglichkeit anhand der fachlichen Anwendungsfälle modelliert werden, statt reine CRUD-Operationen durchzureichen.

Agenda 3.06.2022

  • Dringende Themen
  • keine
  • Alte Todos durchsehen
  • ok
  • Konstantin: Themen-Anmeldung für PI 25. Kandidaten wären z.B: Staging und Releases, Consumer-driven Contract Testing, Observability, ... 
  • CIB: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-93 abschließen, das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-152, das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-24, das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-47
  • Hauptproblem ist, dass Grafana derzeit zu langsam ist und häufig ausfällt.
  • Prioritäten: Account-Migration, Verschlüsselung, Observability/Grafana (47+24), Patch/Schwachstellen,
  • evtl. auch CNP-API (um Localstack abzulösen)?
  • ArgoCD => sinnvoll? von CNP getrieben
  • Staging und Releases? falls von Mngmt priorisiert
  • Konstantin: Das Konzept zu Git-Workflows ist nun final.
  • Bing: Team CIB hat Bedenken, dass Merges in den Master kurz vor Sprintende die Systemtests kaputt machen würden. => Eine Möglichkeit wäre temporär eine Umgebung (s. https://git.tech.rz.db.de/bestellsystem1/infra/bestellsystem-deployment/-/tree/env/development) und dort die Systemtests auszuführen.

288 complete lädt zu einem Termin mit CIB und Konstantin ein.

  • Perspektivisch ist der Einsatz von CDC-Tests zu prüfen.
  • Team CIB: Versionierungskonzept vs. das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-759 
  • anscheinend gibt es Wünsche aus der PO-Runde, ob man mehrere Versionen durch unterschiedliche (Teil-) Umgebungen lösen kann.
  • Statt paralleler Umgebungen sollte man diese Punkte angehen:
  • wie realisiert man Änderungen abwärtskompatibel?
  • wie testet man Abwärtskompatibilität?
  • ist die Architektur (insb. im Bereich AV/SV) vielleicht zu verbessern, um die Abhängigkeiten zu reduzieren?
  • Das Team CIB analysiert im Rahmen von O2CCIB-759 die Anforderungen (zusammen mit PM und Architektur)
  • Konstantin: CDC-Tests (vgl. altes Jira, neue Jira: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-759) => wer könnte einen PoC einführen.

289 complete schaut sich das an und stellt es im nächsten Termin vor.

290 complete : CDC in Team Zero ansprechen, ob hier ein PoC gemacht werden könnte. 

Agenda 20.05.2022

  • Aleksandr: Problem mit schedLock im common-interface
  • Heartbeat-Job ohne Timeout blockierte einzigen worker-Thread => andere Jobs starteten nicht
  • erste Maßnahme: Logging für scheduled Jobs
  • langfristige Lösung: eigener Thread-Pool für Heartbeat-Jobs
  • Diskussions-Exkurs: brauchen wir überall Datenbank-Transaktionen, oder nur in bestimmten Funktionen, oder auf welcher Ebene (per-Nachricht, per-Job, etc)?
  • Aleksandr: Vorstellung Metriken in stammdaten-bereitstellung
  • wann ist es sinnvoll Metriken zwischen zu speichern?
  • dann wenn die Daten nicht schon in einer DB-Tabelle stehen und/oder wenn Werte aus mehreren Pods aggregiert werden
  • dann wenn die Metrik-Berechnung "teuer" ist
  • bei Metriken, die von mehreren Anwendungen bereitgestellt werden (bestellsystem_import_*), müssen wir gleiche Einheiten und Konventionen für ungültige Werte benutzen

Agenda 6.5.2022

  • Bing: Zusammenlegen von APIs (Vorgänge/Verträge/Statistiken-API) in einer API-Repository

279 complete : Termin mit 404, CIB und Konstantin organisieren. => das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-1546

  • Team CIB: Stand der Fortify-Analysen. Umgang mit Prioritäten und Whitelists. Beispiele und nächste Schritte. (vgl. NVD Calculator für CVSS-Berechnung). O2CCIB-666 als Beispiel  
  • Das Vorgehen ist hier dokumentiert.
  • Team Zero (Bernd): Das Team Zero hat (mittlerweile) relativ viele Komponenten. Wir sehen die Gefahr das bei kritischen Fehlern in den Komponenten (z.B. Log4J) die hohe Zahl in einem Team zu einem höheren Zeitbedarf beim Patchen führt. Werden die Bedenken geteilt, gibt es gute Ideen zur "Lösung"?
  •  Der manuelle Aufwand fürs Patchen und Deployen von Umgebungen ist zu groß => Lösungen werden in der CI/CD Runde besprochen.
  • Konstantin: Aktueller Stand MyNet/eBRS, MFA-Einführung und die Planung des Nachfolgesystems (s. Folien).
  • Konstantin: Releases und Updates von Keycloak. Wo stehen wir, wann migrieren wir auf v18 und Quarkus (vgl. hier).
  • Wir sind auf Keycloak 16.x (Helm Chart aber noch auf 15.x) und können erstmal auf 16 bleiben (da kein EOL-Termin bekannt).
  • Team Zero (Norbert):
  •  Java 17 Umstellung => Unsicherheiten, ob wir uns damit nicht eine Schwachstelle (ID?) reinholen.

280 complete : Analysieren, ob in Amazon Corretto behoben, ggfls. Martin und Konstantin fragen. In Trivy ist nur der CVE-2022-22968 drin (Spring Context-Databinder), keine Hinweis auf der Java , Schwachstelle.

  • Whitesource (Inhouse Regeln, Crit High wegen Shedlock)

281 complete Umgang mit Whitelisting (idealerweise global) klären und im CI/CD vorstellen. Policy für Produkt Bestellsystem als Whitelist für der betroffene Bibliothek.

  • Projekt "Migration Testdata tpn-taftap" Archivieren?

282 complete : Verschieben von "apps" nach "tools". Bzgl. der Zukunft mit Bernd und Basil sprechen.

  • Hybrid Tfz Mapping in CI/SB/SV? S. das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-658

283 complete : mit Bernd und Basil sprechen. => s. Diskussionsstand, Abstimmung in PO/PM JF steht noch aus 

  • tdm 2-mal definiert (1x in trassenanmeldungAPI und 1x in versandauftragAPI)

284 complete : Abstimmung und Ergebnis im nächsten Termin vorstellen.

Agenda 22.4.2022

  • Dringende Themen:
  • Diego: Wir müssen ein Vorgehen mit identifizierten Schwachstellen, die ignoriert oder verschoben wurden, definieren oder mindestens eines überlegen.
  • Team CIB arbeitet momentan an einem Enabler, wo dieses Thema eingegangen wird: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-736
  • Team 404 macht das gleich unter das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C404-757

271 complete Wenn beide Enablers fertig sind, wir können einen gemeinsamen Umgang in der nächsten Architekturrunde diskutieren

Agenda 8.4.2022

  • Dringende Themen:
  • Bing: OpenAPI-Generator für Java kommt mit Prefix und Suffix nicht klar (Known Issue mit unschönen Workarounds). Ist das ein Problem? => Nein, passt für alle.
  • Bing: Team CIB möchte Code-Änderungen am Common-Interface (eigentlich Zuständigkeit von Team Zero) vornehmen. Wie ist das Vorgehen?
  • Vorgehen: Ein Team kann jederzeit einen Branch anlegen und einen Merge-Request stellen, das dann vom verantwortlichen Team (in diesem Fall Zero) begutachtet (Review) und akzeptiert wird.
  • Konstantin: Es gibt eine (vorläufige) Übersicht des Benutzermanagements.
  • Dazu die Frage, ob wir aktuell im Portal (bzw. in der Auftragsverwaltung) die Vorgänge nur nach Kundennummern oder auch nach Kanal filtern? => NEIN, das geht momentan nicht, da die Auftragsverwaltung nach Kanal BP filtert, vgl. Umgehung des Kanalzwangs
  • Konstantin: das (von uns standardmäßig für REST-Aufrufe verwendete?) Spring RestTemplate ist im "Maintenance Mode" und soll durch WebFlux Reactive WebClient ersetzt werden. Setzen wir WebFlux bereits irgendwo ein bzw. könnten wir das bei Gelegenheit ausprobieren?
  • NOTE: As of 5.0 this class is in maintenance mode, with only minor requests for changes and bugs to be accepted going forward. Please, consider using the org.springframework.web.reactive.client.WebClient which has a more modern API and supports sync, async, and streaming scenarios.
  • Der OpenAPI-Generator scheint WebFlux bereits zu unterstützen: (verifizieren) => ggfls. als Enabler betrachten.

Agenda 25.03.2022

  • Alte Todos durchgehen
  • Konstantin: Benamung der Stammdaten-APIs ist noch etwas unglücklich Da stehen die Client-Namen als Teil der angebotenen API (stammdatenPMW und stammdatenEVU). 
  • Eine Variante wäre: stammdaten-intern und stammdaten-extern.
  • Perspektivisch: stammdaten-publikation und stammdaten-suche
  • Team Zero soll beim Überarbeiten der APIs neue Namen vorschlagen und in der Architekturrunde absegnen lassen.
  • Norbert: EVU-Callback API soll aus dem CI extrahiert werden. Soll diese umbenannt werden?
  • Vorschlag: versandauftrag 
  • Bernd/Alexander: Neue Schnittstelle zwischen CI und SV für Versandbestätigungen braucht ebenfalls einen Namen.
  • Vorschlag: versandergebnis (Update AlexP, 28.3.22)
  • Konstantin: ADRs trotz Wip mergen?
  • Branches, die nicht mehr weiter bearbeitet werden sollen in den Master gemergt werden. Falls noch nicht final entschieden, dann im Status In Arbeit  und (wip) Vermerk im Index.
  • Martin: ADR 47: 

268 complete Offen ist die Frage, ob Dateien in den Git-Repos abgelegt werden oder direkt in Artifactory => über Gitlab Repo. Ablage zunächst unter qa.

269 complete : mergen

270 complete : neues Ticket für Systemteam - InitContainer und Testdaten-Pipeline, direkt fürs PI 24 S1

  • das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-238
  • das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-239
  • das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-549
  • Verprobung idealerweise in das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-503

Agenda 11.03.2022

  • Martin: ADR 47 vorstellen
  • gewählter Ansatz: kleine Testdatenmengen direkt in Helm (wie schon jetzt an vielen Stellen), bei großen Datenmengen über Artifactory (Upload und Quelle noch zu klären).

262 complete : ADR aktualisieren (Merge in 2 Wochen) => siehe hier

263 complete Ticket für Team Zero, Unterstützung aus dem System-Team => als Kind von das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-151

  • Konstantin: Diskussion und Ideen rund um ADR 35 (Zugriffskontrolle und Authentisierung innerhalb des Bestellsystems).
  • Seitens CNP wird uns ein Service Mesh nahegelegt (siehe AWS App Mesh bzw. Was ist ein Service Mesh)
  • Nach interner Diskussion wurde nun ein Spinoff ADR 48 nur für Verschlüsselung erstellt - darauf wollen wir uns erstmal fokussieren, um die Mindest-Security-Vorgaben erfüllen zu können.
  • Unsere bevorzugte Variante ist TLS in SpringBoot, CA-Lösung ist noch zu klären

264 complete : ART-Enabler extrahieren und 4 Tickets anlegen (CA für Sys, Durchstich für Team Zero, Nachzügler für 404+CIB) => das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-161 (und Untertickets)

  • Bing: Stories das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-911, das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-932,das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-780 besprechen und ob Team-Zero die Stories übernehmen kann. 
  • Team Zero: Aktuelle Ideen bzgl. Stammdaten-Suche (s. das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-323) => Für die Bereitstellung eines AWS Test-Services auf Systemteam zugehen.
  • Konstantin: Branching und Release Prozess - das Thema sollte zwar nicht in PI 24 kommen, wurde aber im Zusammenhang mit EVU-Test Aktualisierungen aktuell.
  • aktuell gibt es hierzu keine "technische" Unterstützung
  • eine mögliche Lösung wäre ein manueller Pipeline-Job nach den System-tests
  • erfordert eine neue Pipeline
  • Überschneidung des Staging und Release-Vorgehen (das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-25)

Agenda 25.02.2022

  • Konstantin: Benutzer- und Rollen Konzept angefangen (Stand hier).
  • Konstantin: Bericht vom gestrigen Meeting der TG "CI Improvements". Das betrifft primär die Aktualisierung des Dokuments D.2 Appendix E
  • Aleksandr/Bishara: asynchrone XSD-Validierung birgt die Gefahr von XML-Injection
  • Scheint unkritisch vorausgesetzt, dass man beim Auslesen von MessageHeader und Sender geprüft wird, dass diese genau einmal vorkommen.
  • Martin/CIB: Spring-Profile als "erweiterte Feature-Flags" benutzen?
  • Anwendungsfall: z.Bsp. Core-Id-Testdatenverarbeitung
  • erscheint sicherer als einfacher if (property) -Abfrage, weil mit Profilen ganze Testklassen in die Anwendung geladen oder nicht geladen werden
  • => soll über die  "@Profile" Annotation aktiviert/deaktiviert werden (das sollte schon jetzt überall so sein!)
  • brauchen wir einen ADR zum gemeinsamen Verständnis und zur Abgrenzung wann die Technik geeignet ist?

258 complete : bitte die Beschreibung im Entwicklerhandbuch auf den neuen Stand bringen

Agenda 11.02.2022

  • Konstantin: RNE hat zur Aktualisierung der Common-Interface und ReferenceFiles-Spezifikation aufgerufen. Welche Painpoints wollen wir platzieren?
  • Hier die Ankündigung und Details
  • Erste Ideen:
  • Hinweistexte mit NACK, evtl. auch weitere Fehlerfälle vorsehen?
  • SOAP-Response sollte Teil der WSDL-Spezifikation sein, statt eine separate XSD
  • Klarstellen, wo die XSD-Validierung erfolgt.
  • Heartbeat spezifizieren statt Freitext mit Beispielen
  • ...
  • Review bzw. Zuarbeit aus den Teams  gerne  direkt  in  den  Word-Dateien

256 complete schaut sich (voraussichtlich) das an und meldet sich.

  • Status der ReferenceFiles-Anbindung weiterhin ungeklärt (Bestellsystem oder IDBF???)
  • Aleksandr/Konstantin: Wo bzw. wann erfolgt bei asynchroner CI die Schema-Validierung? Beim Empfang, vor der Json-Konvertierung oder erst in SV? 
  • Anhand der aktuellen Anlage 2 der EVU-SST muss die Schema-Validierung erst asynchron erfolgen.

250 complete : Vorschlag für die Klarstellung im ADR einreichen.

  • Konstantin: Zusammenfassung der geplanten Maßnahmen aus der Bedrohungsanalyse (s. Excel).
  • Alexander: Neues Feature "Rückmeldeservice". s. das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-134 für PI 24 geplant=> wird  evtl.  schon  früher  kommen.
  • Das Thema wird im PO/PM JF aufgegriffen.
  • Konstantin: Verantwortlichkeit für SQS und S3 an der IFP-Schnittstelle
  • Unser Konsens ist, dass wir der ursprünglichen Planung folgen => S3 und SQS für Vertriebsaufträge kommen von uns, für Produktionsaufträge vom IFP.
  • Optional kann SV prüfen, ob die von IFP in Vertriebsaufträgen referenzierten Buckets wirklich unsere Buckets sind.

254 complete : Enabler für Team CIB für nach PI 23 anlegen. => das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-859

  • Konstantin: Validierung der Daten an internen Schnittstellen (Bsp. PWM => SB).
  • Wir müssen grundsätzlich die Validierung mittels OpenAPI nutzen.
  • Können wir das in irgendeiner Form erzwingen?

Agenda 28.01.2022

  • Annette: Pentest ist fertig. Erstes Feedback ist sehr vielversprechend.
  • Bing: TDM-Artefakte haben nun verschiedene Namen pro Version.

241 complete :Team CIB bereitet einen Vorschlag für die nächste Woche vor. Bing lädt ein.

  • Martin: unsere Postgres-Versionen laufen auseinander (12 bei eigenen Containern vs. 13 bei CNP) => Umstellung auf 13 sinnvoll. Es wird ein Enabler erstellt, das primär von 404 (Annette) übernommen wird. => das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C404-569
  • Norbert: Whitesource-Alerts wegen fehlender Lizenzen bei unseren Bibliotheken wie APIs.

242 complete kopiert das passende Ticket aus dem alten Jira: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-336 => Team Zero (Norbert) übernimmt es.

  • Konstantin: Reviews des ADR 46 besprechen

243 complete Kommentare von Bing einarbeiten und auf Akzeptiert setzen. => erfolgt.

  • Konstantin: log4j-Learnings Teil 2. Einige Abhängigkeiten wurden übersehen. Wie können wir es beim nächsten mal besser machen?
  • Probleme: Benötigte Anwendung-Versionen werden an zu vielen Stellen definiert. Nur noch in Ausnahmefällen die "default"-Versionen überschreiben.
  • Ist eine Automatische Überwachung durch CNP möglich?
  • "händisch": https://bestellsystem1.gitpages.tech.rz.db.de/docs/installierte-versionen/ nutzen.
  • Deployment alter Versionen verhindern. => ist das möglich und praktikabel?
  • Soll im Rahmen von das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-18 zusammen mit CNP betrachtet werden.
  • Mitschrift der Behebung als Anleitung für das nächste mal:

244 complete : Rumpf anlegen und an Bing, Frank, Aleksandr zum Befüllen schicken. => Wiki-Seite

  • Konstantin: Aufnahme der externen Stammdaten-Schnittstelle in die EVU-SST-Dokumentation.
  • Vermutlich schaffen wir es nicht mehr in die Version 4.4.0 => Thema für PO/PM Sync.
  • Konstantin: Monitoring der Umgebungen

245 complete : Feature im PO/PM Sync vorschlagen. => das Thema wird im CI/CD Termin wieder aufgegriffen.

  • Konstantin: Updates der Arch-Dokumentation: DBCS-Infos können weg, Stammdaten-Bereitstellung sonstige Änderungen?

246 complete : Enabler für Zero bzgl. Stammdaten-Bereitstellung erstellen, analog für andere Teams bei Bedarf. => das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-194, das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-448, 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-7720150f306eO2CZERO-447, das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-195

  • Diego: Tests sind recht instabil auf CNP. Für die Analyse braucht man Tracing.
  • CNP muss uns Grafana-Tempo bereitstellen. das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eOO-23
  • Unseren Teil könnten wir proaktiv vorbereiten. das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-89das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C404-568
  • Martin: ich denke wir brauchen einen ADR für den Testdaten-Import
  • ich weiß dass wir vor der aktuellen Implementierung (mit Flyway afterMigrate und wenigen Daten im Helm-Chart) darüber gesprochen hatten, aber ich weiß nicht mehr in welcher Runde und es ist nicht dokumentiert,
  • aktuell wird das Verfahren (und die Datenmenge) bei den Stammdaten in Frage gestellt, so dass eine dokumentierte Bestellsystem-einheitliche Entscheidung sinnvoll ist.
  • Optionen:
  • wenige Daten, defaults im Helm-Chart (also reine Umgebungs-Konfiguration)
  • mehr Daten, in der Anwendung bereitstellen (also Testdaten ins Release-Artefakt)
  • Ein Mock, um den Datenimport zu ermöglichen.
  • anderes?
  • ADR Entwurf

248 complete : Neuen ADR-Entwurf für Testdaten-Importe erstellen (noch leerer MR)

Agenda 14.01.2022

Dringende Themen:

  • Konstantin: Firefox darf ab Februar nicht mehr auf BKU/BWP Rechnern benutzt werden (siehe Anwenderecho)
  • Bing: Team CIB beschäftigt sich derzeit mit der Aktualisierung der TAF/TAP Version. Entgegen der ursprünglichen Planung kann die neue API nicht parallel unterstützt werden, da IFP nur eine Version unterstützen wird.
  • Alex: Im Sprint 2 soll die Testbarkeit des CI verbessert werden, da aber Team Zero aktuell an der asynchronen Nachrichtenverarbeitung arbeitet kann es Abstimmungsbedarf geben. Team CIB kommt auf Team Zero zu.
  • Konstantin: IntelliJ soll auf Floating Lizenzen umgestellt werden. Die ersten Kollegen (u.a. Bishara) haben bereits positive Erfahrungen damit gesammelt.
  • Konstantin: Die neue externe Stammdaten-API ist noch nicht in der öffentlichen API-Dokumentation enthalten. Bernd sucht dazu Gespräch mit Herrn Kuzaj. Es wird eine separate ISGW-Freischaltung für Stammdaten geben.
  • Martin: Log4j-Learnings sollen nächste Woche im CI/CD Termin besprochen werden. Architekturentscheidungen:
  • Konstantin: ADR 45 (asynchrones Fehlerhandling im CI) wurde akzeptiert.
  • : Stammdaten-Anbindung im Portal (siehe hier)
  • geplantes Vorgehen: 2 separate Stammdaten-Schnittstellen im aktuellen PI, Verprobung (mind. einer) Suchengine frühestens im IP-Sprint und die Umsetzung einer Suchengine-Lösung frühestens im nächsten PI

219 complete : ADR vervollständigen und zwecks Review verteilen. (siehe Merge-Request)

  • Es macht Sinn beide Alternativen OpenSearch und CloudSearch zu vergleichen und ggfls. beide zu verproben.

220 complete Enabler für die Auswertung erstellen. => Teil von das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-127

Agenda 17.12.2021

  • Dokumentation

198 complete Konstantin: Architektur-Dokumentation (siehe Merge-Request) akzeptieren

199 complete Konstantin: ADR CI asychron (siehe Merge-Request) akzeptieren. Feedback von Team CIB eingearbeitet.

200 complete : Review bis zum nächsten Arch-Termin durchführen. => OK gegeben.

201 complete Konstantin: Branch für Arch-Änderungen im PI 23 anlegen und verteilen. => Branch, siehe auch wichtigste Todos im Merge-Request

202 complete Konstantin: Stammdaten-Bereitstellung in Arch-Doku statt Stammdaten-Adapter hier beschreiben.

203 incomplete : besprechen, wer das aus Team Zero übernehmen kann.

  • Sonstiges

204 complete Konstantin: Status log4j2-Schwachstelle

  •  SonarQube wurde abgeschaltet
  • Frank ist dabei localstack zu aktualisieren. Skripte sind dafür anzupassen. Zuerst DBCS dann CNP.
  • Keycloak ist voraussichtlich nicht betroffen.

205 complete Konstantin: Serie fürs nächste Jahr terminieren => läuft ab dem 14.1.22 weiter.

206 complete Norbert: Fragen zum parent-pom. Wäre es nicht besser als Dependency (BOM) zu handhaben? Nach Rücksprache passt es so als parent-pom.

207 complete Konstantin: Status Stammdaten-Anbindung

208 complete Norbert: Termin mit Annette und Konstantin organisieren, ab 10.1. Es ist weiterhin geplant, die selbe API für Portal-MW bereitzustellen.

Agenda 3.12.2021

  • Dringende Themen
  • Konstantin: ADRs durchgehen (siehe Tabelle oben)
  • Konstantin: Hochheben der TAF/TAP API Version in PI 23 soll ohne Big-Bang erfolgen sondern Schnittstelle für Schnittstelle migriert werden. Voraussichtlich in der Reihenfolge: AV => SV => Portal/CI
  • Bing: Team CIB hofft, dass viele Schnittstellen abwärtskompatibel gehalten werden können.
  • Diego: Team 404 braucht 2 Versionen von CIB sobald nicht abwärtskompatible Änderungen vorhanden sind.
  • Martin: Team CIB erstellt gerade eine Parent-POM für SpringBoot-Anwendungen.

179 complete : bitte die parent-pom von anderen Teams reviewen lassen.

  • Diego: Restliche Schnittstellen (AV <= Portal-MW und SV <= Portal-MW) sollten ebenfalls als SST-Projekte angeboten werden. Aktuell muss man noch die OpenAPI-Definitionen kopieren.
  • Bing: das liegt bei CIB im Backlog. Der erste Teil (Trassenameldung) soll im aktuellen IP-Sprint angegangen werden. 
  • Asynchrone Verarbeitung der Nachrichten im Common-Interface soll vom Team Zero übernommen werden. Zunächst parallel zu fachlichen Änderungen durch Team CIB. Ab PI 24 evtl. auch komplett. Siehe ADR oben.

180 complete : wird im Zero-Refinement am 6.12 besprochen (vorab Info an Bernd).

  • Konstantin: Freigabe der Qualitätsänderungen in der Arch-Doku => Merge durchgeführt.
  • Die Stammdaten-Bereitstellung soll den Stammdaten-Adapter ablösen => Umstellung der Portal-MW notwendig (siehe ADR oben). Diskussionsbedarf zur Indizierung!

181 complete : Abstimmten mit Team 404, dass das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C404-400 in PI 23 berücksichtigt wird => falls Aufwand überschaubar, so wird das Thema Suche erstmal aufgeschoben.

  • Stammdaten-Verwaltung ist als Abkürzung zu ähnlich zu Steuerung-Vertrieb.

182 complete : Polling in einem (welchen?) Teams-Kanal.

Termin 19.11.2021

  • Dringende Themen
  • Probleme mit den Systemtests weiterhin vorhanden. => Ist am 25.11 im Tester-JF zu diskutieren!
  • ADRs
  • Konstantin: asynchrone Fehlermeldungen in Common-Interface (s. oben).

165 complete : klären mit PO/PM für wann das einzuplanen ist. => Benjamin legt hierzu ein Feature an. Story-Schnitt TBD. Anpassung der Anlage 2 der EVU-SST vor Mitte Januar nötig!

  • Konstantin: ADR 23 - Keycloak bleibt erstmal unverändert, da eine Alternative für Keycloak nicht in Sicht ist. Unsere Annahme ist, dass auch mit Keycloak.x sich für uns nichts wesentliches verändert.
  • Dokumentation
  • Konstantin: Aktualisierung der Architekturdokumentation für PI 22. Der vorläufige Stand ist hier zu finden. Review (auch für Ergänzungen) aus den Teams gesucht.

166 complete : Input für Team 404 sammeln

167 complete : Input für Team CIB sammeln

168 complete : Input für Team Zero sammeln

169 complete : Input integrieren und das Ergebnis zum Review freigeben.

  • Konstantin: Feedback zum Domänenmodell (siehe Post)?

170 complete : Aufnahme in die Testdoku (als draw.io Diagramm? => Karl-Heinz angeschrieben)

171 complete : Abstimmung mit POs (Termin zwecks Definition findet am 1.12.21 statt)

  • Sonstiges
  • Martin: Brauchen wir einen Plan oder Ansprechpersonen über die Weihnachtsfeiertage? – Vertriebsdemo und EVU-Test können wir dieses Jahr vermutlich nicht einfach abschalten.

172 complete : auf ART-Ebene und bei CNP erfragen. => CNP wird doch Support anbieten, wenn auch mit reduzierter Mannschaft. Alle Umgebungen können online bleiben.

  • Umstieg auf Java 17 und Migration von Java 11 (der Java 11 Support endet im September 2023).  SpringBoot unterstützt  bereits  Java  11.

173 complete : ART-Enabler für 2022 aufplanen. siehe das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-93

174 complete : Nach Status/Plänen bei Camunda nachfragen. offener Feature Request für Release 7.17 https://jira.camunda.com/browse/CAM-13816 wurde von Camunda Support bestätigt, dass die Unterstützung mit 7.17 kommen soll, Releasetermin noch nicht fixiert, nach dem bisherigen Releasezyklus wäre es Ende Mai 2022.

  • Konstantin: Versionierung der APIs wird ab PI 23 zur Pflicht! (hier noch Link zu REST API Design - Versionierung)
  • Ein API-Anbieter dürfen seine API-Konsumenten nicht durch nicht-abwärtskompatible Änderungen kaputtmachen.
  • Mögliches Vorgehen: im PI-Planning wird eine API-Änderung geplant. Producer entwickelt die Schnittstellen weiter, Consumer passt nachgelagert an, am Ende des PI (notfalls am Anfang des Folge-PI) wird die alte API ausgebaut. 
  • Bing: Abhängigkeit von AV-APIs zu data-model sollen abgeschafft werden.
  • künftig ist bei Änderungen des TDM dann immer bei Team 404 anzufragen, ob dies auch in der Vertrags-API und Vorgangs-API zu exponieren ist.

Termin 5.11.2021

  • Dringende Themen
  • keine
  • Todos aus Vorterminen => wurden bereinigt
  • Diverses
  • Martin: brauchen wir sowas wie eine einheitliche Liste für (Prometheus-)Metrik-Namen?
  • zum Beispiel hat jetzt jedes Team eine Komponente mit Daten-Import. Der einfache Ansatz wäre nun für jeden Import eigene Metriken zu erzeugen:
  • bestellsystem_last_import_timestamp_bbz
  •  bestellsystem_last_import_timestamp_kundendaten
  •  bestellsystem_last_import_timestamp_stammdaten
  • vielleicht auch bestellsystem_last_import_timestamp_ordnungsrahmen
  • im Prometheus-Datenmodell und -Namensschema (und später für die Grafana-Queries dagegen) wäre aber eine einzelne Metrik mit Labeln besser:
  • bestellsystem_last_import_timestamp{type="bbz"}
  • bestellsystem_last_import_timestamp{type="kundendaten"}
  • bestellsystem_last_import_timestamp{type="stammdaten"}
  • vielleicht auch bestellsystem_last_import_timestamp{type="ordnungsrahmen"}
  • Variante (ii) soll verfolgt werden. Bitte in das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C404-60 (sowie das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-38) berücksichtigen und im Entwicklerhandbuch unter Monitoring als Vorgabe aufschreiben.
  • Bing: durch die Änderungen der (strengeren) Validierung der Schnittstelle "Trassenanmeldung" kann es Verhaltensänderungen kommen, die Auswirkungen auf Team 404 haben könnten.
  • Team CIB läßt die neue Version vorab von Team 404 testen.
  • Künftig könnten wir uns hierfür CDC Testing anschauen (entweder in einem IP-Sprint oder im PI als Enabler) 
  • Umstieg auf Camunda-EE ist erfolgt.
  • Fehlende Dokumentation unseres Bestellsystem-weiten Fachliches Datenmodell (vgl. bzw. )

146 complete : Gedanken machen, Termin organisieren und Termin organisieren (+Alexander, Basil, Dominic?)

  • Konstantin: Umgang mit Retries, besonders im Umfeld der CI-Kommunikation mit EVUs.
  • Reaktion auf Duplikate (ACK vs. ERROR)
  • Empfehlung wann EVUs Retry-Nachrichten senden sollen, z.B. bei 500-er SOAP Fehlern und Timeout.
  • Aktuelles Beispiel Cargo => CI-Router (Team COS) => Bestellsystem

147 complete : Termin für eine Analyse organisieren. (geplant für 17.11.2021)

  • Qualitätsszenarien  (in  Confluence)

148 complete : Confluence-Seite verlinken

  • Umgang mit Stammdaten: hier fehlt eine  Übersichtsseite  (in  Confluence)

149 complete : mit Christian Meins abstimmen und dokumentieren (zunächst mit Bernd und Benjamin, Folgeabstimmungen geplant).

Termin 22.10.2021

  • Martin: neue K8s-Namespaces bei CNP weil wir jetzt Umgebungen nach CNP migrieren wollen, möchte ich gerne einen groben Plan für die Verteilung der Umgebungen auf Namespaces besprechen. Alles im Rahmen eines EKS-Clusters, d.h. die Pods teilen sich die Ressourcen der geteilten Server/EC2-VMs. Die Benutzung von Fargate ist prinzipiell unabhängig davon, die können wir bei Bedarf in mehreren Namespaces aktivieren (bisher ist das von CNP nur im Namespace bestellsystem-fargate  konfiguriert, Config in Git) Mein Vorschlag für neue Namen und ihre Benutzung sind im Ticket O2CZERO-84 und im Entwicklungshandbuch unter laufende Namespaces/Umgebungen:
  • bsz-ieu - für neue IEU
  • bsz-demo - für Vertriebsdemo und mögliche andere Schulungs-/Demo-Umgebungen
  • bsz-build - Build-Pipelines (und SonarQube)
  • bsz-test - quasi alles andere, so wie bisher auch in DBCS: development, AT/Review, System-Integrationstest (?), eigene Dev-/Test-Instanzen
  • Martin: ganz kurze Beschreibung von Ressourcen-Requests in Kette CNP-API → Crossplane → AWS sollten wir in künftigem CI/CD-Termin nochmal aufgreifen wenn mehr Entwickler API-Zugriff bekommen

Termin 8.10.2021

  • Dringende Themen
  • Konstantin: KDA als Blaupause für die Stammdaten-Verwaltung. Diese soll von Norbert aus Team Zero im Kontext von Team CIB umgesetzt werden. (Zur Info)
  • Konstantin: Ab Ende Oktober voraussichtlich mehr Zeit für das Bestellsystem.
  • Bing: Versionierungskonzept
  • Als Arbeitsstand akzeptieren.
  • Am konkreten Beispiel durchspielen (voraussichtlich PI 23).
  • Grundsätzliches Problem ist die Wiederverwendung des TDM (internen Datenmodells) an unterschiedlichen Stellen inkl. Portal-Anbindung. Hier überwiegen aktuell aber die Vorteile.
  • Bing: Integrationstests mit RNE-Referenzimplementierung
  • Soll im Team CIB, vor allem mit PO diskutiert werden.
  • Liste von bekannten Problemen mit der CI-Kompatibilität.
  • Konstantin: Architektur-Abnahmen
  • Bitte an die Teams verstärkt Einzel-Review-Termine pro Enabler (ggfls. Story) zu machen.
  • Konstantin: Konstruktion der User Story. Dies könnte im Rahmen des User-Pipeline-Schritts "Review Dev" erfolgen.

Termin 24.09.2021

  • Dringende Themen
  • n/a
  • ADRs
  • Martin: FYI: ich werde den ADR zur Secrets-Verwaltung aktualisieren... => kann als Konzept mit einem tieferen Detailgrad weitergepflegt werden.
  • Fortschreibung der Architektur für PI 22
  • Alexander: Attachments für Rahmenverträge im CI
  • Zwar voraussichtlich kein Thema für PI 22, aber hat Auswirkungen auf den Kanal für die Übermittlung der Rahmenverträge (über CI oder separat?)
  • Zugehen auf Kunden (z.B. IVU), ob das mit Referenzimplementierung möglich ist.
  • Architekturentscheidung fällig

138 complete : initiale Version erstellen (verschoben auf ADR-Tabelle).

  • Konstantin: Stammdaten-Verarbeitung 2.0
  • Integration in Kundendaten-Adapter kein Thema (wg. unterschiedlicher Schutzbedarfe der Daten), aber KDA durchaus als technische Vorlage denkbar
  • Vorschlag für das neue System: Stammdaten-Bereitstellung (in Abgrenzung zum Stammdaten-Adapter)
  • Genauere Spezifikation zwecks exakterer Schätzung notwendig
  • : an Enabler/Story vor Sprint 3 ergänzen.
  • Konstantin: Szenarien (auch Qualitätsszenarien) sollen im PI 22 überarbeitet werden.
  • Pentest Portal: hat der Umbau auf das "flache Popup" Auswirkungen auf das Pentest-Vorgehen bzw. dessen Aussage?
  • Annahme: nein, da sich die API zur Portal-MW höchstens marginal ändert.

139 complete , : Es gibt keine Auswirkungen, da das flaches Popup nur geringfügige Änderungen im Objekt-Modell der SST zwischen UI und MW verursachen wird. Die Endpunkte werden so bleiben, wie sie jetzt sind.

  • Lizenzen

140 complete : Übersichtsseite in Confluence anlegen und verlinken + bekanntgeben (verschoben bis zur Konstituierung des Systemtests Anfang 2022)

  • Bing: TDM-Versionierung vorstellen

141 complete : Doku ins Konzept überführen

142 complete : nächste Schritte abstimmen. Die Teams sollen an den künftigen SST-Änderungen das Konzept verproben.

  • Konstantin: Stand CI-EVU-Tests: gibt es hier grundlegende Probleme (z.B. beim Fehlerhandling), die einen Entscheidungsbedarf und Aufwände erfordern?
  • Fehler entstehen aus verschiedenen Gründen inkl. fachlicher und technischer Kommunikation, sowie unzureichender Fehleranzeige in RNE-CI.
  • Der aktuelle Stand soll hier aktualisiert werden.

Termin 10.09.2021

  • Dringende Themen
  • Martin: Organisation der Security-Scanner, wann, wie oft etc.
  • Planung das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-18
  • Alexander: Wie ist der Status zum endgültigen Wechsel zu CNP? 
  • Notizen von Martin:
  • Bisher hatten wir den Blocker dass alle DNS-Namen und LoadBalancer-Hosts manuell konfiguriert werden mussten. Das machte Test-Deployments schwierig und AT-/Review-Deployments unmöglich.
  • Als Backup-Plan, falls es bei CNP länger nicht funktioniert, testen wir bei DBCS auf das neue OpenShift 4 zu wechseln (BSQ-554). 
  • Jetzt (seit 1.9.) haben wir einen Ingress Controller (LoadBalancer-Config) und Zugriff auf die CNP-API (um DNS-Namen anzulegen); Status in BSQ-501. Das sind jetzt zumindest die Tools mit denen wir weiterkommen, damit versuche ich das Setup jetzt so zu automatisieren dass unsere CI-Pipelines ohne große Änderung auf CNP funktionieren.
  • Nächste Hürden, aber hoffentlich keine Blocker, sind dann andere offene CNP-Bugs BSQ-586 und die Skalierung der Build- und Test-Umgebungen.
  • An der Stelle auch eine Frage in die Runde: ich will jetzt bei CNP mehrere K8s-Namensräume anlegen (zumindest mal build und test). Hat jemand Vorschläge für ein gutes Namensschema? Oder eine Meinung ob wir die OpenShift-Namen "bestellsystem-build", "bestellsystem-test" auch bei CNP benutzen wollen?
  • Planung das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-28
  • Aktuell doppelte Aufwände bei Entwicklern zwecks Analyse
  • Reihenfolge der Umgebungsmigration
  • statische Umgebungen zuerst?
  • Kommunikation von Problemen

133 complete : alle Entwickler im CNP-Teams-Kanal aufnehmen  → ich hoffe ich hab alle betroffenen in der Liste

  • Diego: wann kommt das Publizieren von OpenAPI-Spezifikation in allen Anwendungen?
  • Geplant für APIs des Teams CIB und KDA in PI 22 geplant.
  • Konstantin: Architektur-Themen für PI 22 (Diskussionsstand)
  • Infrastruktur
  • Pentest und Freischaltung Portal !
  • DBCS => CNP !
  • Überwachung
  • Logging !
  • Test
  • Tests RNE CI ?
  • Systemintegration !
  • LuP 2 !
  • Testdaten-Strategie
  • Runway
  • Stammdaten-Adapter neu bauen???
  • Patch und Schwachstellen !
  • API-Versionierung !
  • Feature-Support
  • Rahmenvertrag als Sonderfall eines PathRequests…
  • Anhänge?
  • Rahmenverträge !!!
  • Externe Stammdaten-Schnittstelle???
  • Kundendaten verwerten !

Termin 27.08.2021

  • Dringende Themen?
  • Annette: Passwort-Verwaltung in Java (vgl. Fortify Findings)
  • Fortify moniert, dass Zugangsdaten (hier für BasicAuth Richtung BBZ) übertragen werden.
  • Hierfür gibt es keine Lösung, da BasicAuth seitens BBZ vorgegeben ist und das Passwort im Java Prozess ähnlich sicher ist wie Kubernetes Secrets in eingebundenen Dateien.
  • Alexander: Einbindung Kundendatenadapter im PI 22 CIB geplant. Gibt es hier noch Umbau-Pläne?
  • Nein, kann gerne in CIB angebunden werden.
  • Zu beachten ist, dass KDA noch nicht in allen Umgebungen installiert wird (insb. EVU-Test)
  • Kunden-Daten aus 404 und CIB müssen zusammen passen. Hier finden noch Abstimmungen statt.
  • Aktuell ist CompanyCode im Portal noch hartkodiert.
  • ADRs
  • Vorstellung ADR 39 Stammdaten-Adapter Neu
  • Vorgestellt und (trotz der Unsicherheiten bzgl. der Ausgestaltung der EVU-Test SST, Caching-Details und Excel-Stammdaten) angenommen
131
complete
akzeptieren

Termin 13.08.2021

  • Dringende Themen?
  • Unterschiedliche Nutzung der Development-Umgebung in den Teams 404 und CIB führt zu Integrationsproblemen.

122 complete und besprechen die Verschaltung und stellen das Vorgehen am 19.8 in der Tester-Runde vor, alternativ am 20.8 in der CI/CD Runde vor.

  • Umgang mit inkompatiblen Änderungen der internen Schnittstellen. Es gab Absprachen zwischen Teams 404 und CIB.

123 complete bereitet eine Beschreibung des abgestimmten Vorgehens vor. Das hier kann als Grundlage benutzt werden.

  • Offene Punkte durchgehen
  • Versionierungkonzept (siehe oben)
124
complete
Termin mit Bing und Diego/Annette einstellen.
  • Diverses
  • Konstantin: Notwendigkeit der neuen Bedrohungsanalyse? Neuerungen seit Dez 2020: IFP-SST, AC-Trasse SST, interne SSTs Portal-Backend.
125
complete
beim Team AppSec bzw. CNP, NVI 6 bzw. Holger anfragen
  • Konstantin: Vorbereitung des PEN-Tests fürs Portal.
  • Team 404 bereitet die Härtung des Portals vor.
  • Keycloak ist die größte Baustelle.
  • OWASP-Findings überschaubar.
  • Konstantin: Erfahrungen und Stand bzgl. OpenAPI-Publikationspipeline (auch basierend auf den eigenen Erfahrungen mit stammdaten-extern).
  • Team CIB hat mit der IFP-API angefangen.
  • Vorgänge werden noch nicht genutzt. → Thema fürs IP-Sprint.

126 complete  Enabler anlegen und im Planning ansprechen. 

  • Team 404 nutzt das für die Portal-MW API.
  • Performance-Findings
  • SystemTest Probleme: Absenden-Popup im UI für PathRequest absenden prüft auf fertige Trassenkonstruktion → 

127 complete  organisiert einen Termin mit Karl-Heinz, Alex/Christian und Benjamin (alternativ Marcel oder Ana) - Nach Absprache mit Team CIB haben wir festgestellt, wir müssen die System-Tests anpassen und ich habe dafür einen Enabler erstellt: JIRA bei VS FIBf8bee427-878b-3e23-93d2-1b668530ab51BSTEAM-2702

  • PortalMiddleware prüft alle vorhanden Aufträge für das UI Absenden-Popup, statt nur den einen explizit abzufragen → siehe 

128 complete (und Annette) kommen auf Alex zu: evtl. neue Methode in Auftragsverwaltung anfordern - Nach Absprache mit Alex haben wir festgestellt, dass eine neue Methode nicht nötig ist, aber es gibt immer noch einen Bug im Portal zu korrigieren. Das entsprechende Ticket wurde in Jira erstellt: JIRA bei VS FIBf8bee427-878b-3e23-93d2-1b668530ab51BSTEAM-2701

  • ADRs durchgehen
  • Konstantin: Vorbereitung ADR 39 - Stammdaten-Adapter neu sollte vor  PI-Planning erfolgen, um eine sinnvolle Planung zu ermöglichen.
  • Team CIB benennt heute Nachmittag Vertreter.
129
complete
organisiert einen Termin.
  • Team 404 macht Review.
  • ADR 44 Monitoring

130 complete kann akzeptiert werden.

  • ADR 35 - interne Schnittstellen
  • aufschieben, bis Service Mesh bereit steht
  • weitere ADRs

Termin 16.07.2021

  • Dringende Themen
  • keine
  • Konstantin: Kapitel 5 der Architektur-Dokumentation wurde überarbeitet.
  • Siehe Merge-Request
105
complete
Review bis 22.07 => danach Merge
  • Konstantin: Brauchen wir eine Nomenklatur für Schnittstellen?
  • führend sind die fachlichen Bezeichnungen: WiP in Confluence (liegt bei BEs)
  • auf jeden Fall gilt Anwendungsname <> Schnittstellenname (wegen der 1:n Beziehung)
  • Konstantin: Versionierungsvorschlag:
  • siehe Branch, ggfls. als Konzept weiterführen.

106 complete   und Review und weitere Vorschläge bis 30.07 (nächste Diskussionsrunde)

  • Konstantin: Ideen zur Weiterpflege der Dokumentation
  • Wunsch: Multi-Page Ansicht statt einer Riesen-HTML-Seite (vgl. Micromaster und multipage-Projekt)
  • andere Ideen/Vorschläge?
  • Entscheidung: vorerst keine Änderungen bis der Änderungsdruck größer wird.
  • Konstantin: Infos zu Keycloak, Inter-Service-Verschlüsselung, Service-Mesh ...
  • Initiative "common identity provider" wurde gestartet => noch kein Betreiber-Team in Sicht.
  • hätte Auswirkungen auf die Gestaltung der Login- und Datenschutzhinweis-Seiten
  • IFP und IDBF streben explizit produktiven Einsatz eigener Keycloak-Instanzen an, um UI-Auth und API-Auth zu lösen.
  • CNP-Lösung (Service-Mesh und Identity Provider) in Arbeit => Ergebnisse bis Ende PI 21 erwartet.
  • Nächste Schritte im ADR 35
110
complete
spätestens bis Ende PI 21
  • ADRs prüfen
  • ADR 36 (Deployment, siehe oben)
  • aktuelle Arbeiten von Frank ändern zwar einige Umsetzungsdetails aber nicht das dokumentierte Konzept.
  • wird akzeptiert.
  • ADR 37 (API-Publikation, siehe oben)
107
complete
Merge-Request zur PoC-API prüfen und akzeptieren
108
complete
ADR akzeptieren
  • Nächster Termin am 30.7
  • Konstantin nicht da
  • Moderation übernimmt: 

Termin 02.07.21

  • Team 404: Kann http/2 fürs Portal aktiviert werden um Performance-Verbesserungen zu aktivieren? Dies kam im Rahmen der Bewertung mit Lighthouse. (TODO: Link)
  • Martin: zur Diskussionsgrundlage https://git.tech.rz.db.de/-/snippets/661
  • Unsere Annahme ist, dass dies nur für die Strecke Kunde-ISGW relevant ist.
  • Anfrage bei CNP gestartet.
  • Umsetzung im Rahmen der Portal-Tests im Internet.
91
complete
Enabler erstellen. JIRA bei VS FIBf8bee427-878b-3e23-93d2-1b668530ab51BSTEAM-2570
  • Auswirkungen auf Test-Design? Relevant für LuP inkl. Portal.
  • Konstantin: Versionierung der (internen) Schnittstellen: Müssen wir Abhängigkeiten zu data-model auflösen? Einheitliche vs. getrennte Versionierung der APIs.
  • Teil von ADR 37 aber erweitert um die Problematik von data-model.
92
complete
Konzept für die API-Versionierung beschreiben. in ADR 37 einarbeiten (wip)
  • der aktuelle Stand von JIRA bei VS FIBf8bee427-878b-3e23-93d2-1b668530ab51BSTEAM2-996 vorgestellt (von Bing). Offene Fragen u.a.
  • Wiederverwendung das Datenmodells aus data-model weiterhin sinnvoll?

93 complete Muss im Team CIB weiter diskutiert werden. (bleibt weiterhin als shared Projekt)

94
complete
Push (ohne Force) auch im Gitlab-Projekt Architektur deaktivieren
  • Konstantin: (Frage an Team CIB) gibt es schon Abstimmungen mit IFP (Team 3) bzgl. der Veröffentlichung der openapi specs für Produktion- und Vertriebsaufträge? Siehe auch ADR 13.
  • Laut Konzernvorgaben sollten solche APIs zwischen Systemen (gilt nicht für System-interne Kommunikation) über BizHub veröffentlicht werden (auch wenn sie nicht über BizHub) konsumiert werden.
  • Wie das funktioniert, vor allem mit Pipeship, können wir auch bei AC-Trasse abschauen.
  • Im kommenden CIB Sprint wird es Änderungen an Vertriebsaufträgen geben.

95 complete IFP fragen (Joachim/Zülfükar/S.Hartte) und Enabler für Team CIB erstellen

96 complete Austausch mit AC-Trasse organisieren

Termin am 18.06.21

  • Aktuelle Themen?
  • Konstantin: Architektur-Diskussionen bevorzugt über den Teams-Architektur-Kanal führen um die Sichtbarkeit und Auffindbarkeit im Projekt zu erhöhen.
  • Infos
  • Konstantin: Bericht von JSG TEG Planning - CaseReferenceObject mit xs:any
  • Aussichten für analoge NSP-Modellierung in TAF/TAP TSI sehr schwierig
  • Architekturentscheidungen
  • Konstantin: zur Info ADR 41: Pipeline-Migration
  • Martin: ADR 38 - Aurora → akzeptiert
  • Martin: 42. Spring Cloud Kubernetes → akzeptiert
  • Sonstiges
  • Konstantin: ADR vs. Konzept, Beispiel ADR 36 - eher ein lebendes Konzept?
  • CIB/404: Status OpenAPI-Spezifikation und Publikation
  • Bing: wurde im IP-Sprint nicht geschafft, eher ein Thema für Sprint 1
  • Konstantin: Vorgehen bei SST-Abstimmungen (bsp. AC-Trasse).
  • Vor- und Nachteile transparenter machen, Abstimmung mit AC-Trasse und Feedback von Jason stehen noch an.
  • ADR 43 Anbindung Dokumentationsservice wurde von Alexander vorbereitet  

50 complete  : nach Abstimmung mit AC-Trasse wird ADR 43 aktualisiert.

Termin am 08.06.21  (Ausweichtermin für 04.06.21)

  • Diego: Team 404 würde gerne in JIRA bei VS FIBf8bee427-878b-3e23-93d2-1b668530ab51BSTEAM-1981 OpenAPI Publikation nutzen, die aber (parallel) von Team CIB in  JIRA bei VS FIBf8bee427-878b-3e23-93d2-1b668530ab51BSTEAM2-996 verprobt wird.
  • Alexander: Verbesserung der NSP-Modellierung in TAF/TAP TSI.
  • 2 Vorschläge präsentiert: basierend auf EIU-spezifischen Includes bzw. xs:any mit Namespaces
  • Notwendigkeit der XSD-Validierung der NSPs gegeben? Hauptgrund ist eine frühe  Validierung im CommonInterface
  • Kompatibilität mit RNE CI muss sichergestellt werden
  • Es sollte nicht zu kompliziert werden.
  • Konstantin: Camunda Enterprise Edition
  • kann das in PI 21 angegangen werden? 
  • Kostenschätzung als Teil des ART-Enablers (und PI-Risiko)
  • Gibt es eine Notwendigkeit für den Einsatz?
  • Debugging und Historisierung
  • Security Patches

Termin für 21.05.21

  • Alte Todos durchgegangen
  • Verbesserung der NSP-Modellierung in TAF/TAP TSI - Team CIB hat visionäre Ideen. 
  • ADR 40. Wechsel auf CNP - vorgestellt, diskutiert und akzeptiert
  • ADR 37 besprochen
48
complete
Enabler für Team CIB zur Verprobung der 3. Alternative bis Planning am 26.05 vorbereiten: JIRA bei VS FIBf8bee427-878b-3e23-93d2-1b668530ab51BSTEAM2-996
  • Termin am 4.6 soll wegen Brückentag verschoben werden.

Termin für 07.05.21

  • IFP-Mock: wird zunächst auch in SpringBootIntegration-Tests von Steuerung-Vertrieb genutzt
  • In JIRA bei VS FIBf8bee427-878b-3e23-93d2-1b668530ab51BSTEAM2-1536 wird er voraussichtlich wieder ausgebaut
  • Umgebungen werden in Confluence unter Umgebungen dokumentiert 
  • Gerne dort nachschauen und pflegen
  • Schnittstellen wurden initial dokumentiert

38 complete OpenID-Connect Endpunkte zusammenfassen

39 complete OpenAPI Spez für den Infra-Manager besorgen und 404 bereitstellen (hier verlinkt)

40 complete Enabler für Evu-Callback Extraktion und Bereinigung erstellen (analog SV und AV) 

41 complete Enabler für OpenApi-Einführung in Kundendaten-Adapter soll in SV-Einbindung berücksichtigt werden (Enabler BSTEAM-2206 angelegt)

42 complete Neue Schnittstellen in AV/SV ergänzen

  • ADR 37 - OpenAPI
  • OpenAPI-Repo für Vertriebsauftrag-Schnittstelle zwecks Zusammenarbeit mit IFP erstellen

43 complete Enabler anlegen (falls keine geeignete Story vorhanden) → für Linter auf Martin zugehen

44 complete ADR 37 aktualisieren (vgl. Infos vom 23.4)

  • Bing/Alex: IFP-Schnittstelle Vertriebsauftrag-Nachrichtenmodell: Abbildung von Nichtkonstruierbarkeit von Ablehnung mit Änderungswunsch
  • Variante mit Nachrichtenwiederverwendung empfohlen. Team CIB übernimmt die Pflege.

Termin am 23.04.21

  • Annette/Bing: Vorstellung ADR 37
  • Grundlegender Vorschlag
  • ein Repository für alle APIs (später evtl. geteilt nach Teams und/oder intern/extern)
  • Publikation als openapi-Datei (gitpages oder generic-repo), Java-Client (Maven), Java-Server (Maven), Javascript-Client (NPM)
  • Wichtig: openapi-Datei muss mit aufgelösten Querverweisen publiziert werden.
  • Offene Fragen bzgl.
  • Versionierung muss auch Branches (z.B. Snapshots) unterstützen und Version mit der Pipeline-Version synchronisieren
28
complete
Erfahrung von AC-Trasse einholen: Ein gemeinsames Repository (hier) für alle APIs, Maven-Sub-Modul pro API, generiert Java-Bindings.
  • unterschiedl. Anforderungen an Clients (Spring MVC vs. Jax-RS etc.)
  • iteratives Vorgehen: zuerst Publication von openapi-Dateien und Code-Generierung weiterhin in Client und Server

29 complete  kann OpenAPI-Generator mit externen URLs umgehen (Security-Thema?) → nein, funktioniert nicht

  • Wiedervorlage beim nächsten Termin
  • Konstantin: Technische Schulden und Risiken
  • Bing: Vorstellung Namensschema für REST-Schnittstellen am Beispiel der neuen Vorgänge-API in Auftrags-Verwaltung-Trasse.
  • Schema: //v/ (vgl. API-Guidelines)
  • Übersicht über bisherige Schnittstellen-Namen
30
complete
bereitet eine Übersicht der bisherigen OpenAPI-Schnittstellen vor → Ergebnis
  • Konstantin: Erweiterung der Bausteinsicht: Beschreibung der Komponenten und der internen Schnittstellen inkl. Namen, NFAs etc.
  • Beispiel fürs Common-Interface ist hier zu finden. Für Teams wurden einzelne Tickets erstellt: JIRA bei VS FIBf8bee427-878b-3e23-93d2-1b668530ab51BSTEAM-2036, JIRA bei VS FIBf8bee427-878b-3e23-93d2-1b668530ab51BSTEAM2-1513, JIRA bei VS FIBf8bee427-878b-3e23-93d2-1b668530ab51BSQ-434
  • Konstantin/Annette: Anbindung eBRS/KDV ist zu aktualisieren: KDV wird bisher nur im Kundendaten-Adapter angebunden. Dieser aber noch nirgendwo verwendet.

Termin am 09.04.21

  • Neuigkeiten und Dringliches
  • Erster Durchstich Portal-Middleware zur Steuerung-Vertrieb erfolgt
  • Es werden Umgebungen für Integrationstests benötigt
  • aktueller Stand ist hier zu finden

12 complete Es gibt Überarbeitungsbedarf → CI/CD Runde

  • Integration mit Umsystemen ist geplant in JIRA bei VS FIBf8bee427-878b-3e23-93d2-1b668530ab51BSQ-354 und JIRA bei VS FIBf8bee427-878b-3e23-93d2-1b668530ab51BSQ-384
  • ADRs
    1. Publikation der Schnittstellen-Spezifikationen  ist in Arbeit
  • ADR für Stammdaten-Adapter soll initialisiert werden
14
complete
erstellt eine initiale Version
  • ADR für Einsatz von AWS Aurora statt AWS RDS (weiterhin als PostgreSQL)

15 complete Martin erstellt ersten Aufschlag

  • Versionierungskonzept hier wird im Rahmen der Migration auf EVU-SST Version 4.2.x verprobt
  • Konstantin: Bericht von der Teilnahme an der "Core Group 7 - Architecture und Cybersecurity" und der geplanten Fortentwicklung der TAF/TAP Spezifikation

16 complete Konstantin: Ablage im Sharepoint ist erfolgt hier

17 complete Saurav/Alexander: Ideen für NSP-Verbesserung in TAF/TAP intern vorstellen

  • Konstantin: Anpassungen an Architekturdokumentation im PI 20

18 complete Konstantin: Anbindung Portal ans Backend → Termin mit Alexander und Annette

  • Konstantin: erstmal nur zur Info - aktuelle SLA-Modelle sind im Sharepoint zu finden.
  • Annette: Übersicht der Schnittstellen-Beschreibungen inkl. Ansprechpartner ist hier in Confluence zu finden.

Termin am 26.03.21

  • Konstantin: Schnittstellendokumentation in Confluence ist noch sehr ausbaufähig :  - brauchen wir hierzu "Kümmerer"?
  • Annette spricht im Team 404 wegen BBZ Dokumentation
  • Alexander beschreibt die neuen internen APIs zwischen CIB und 404 ebendort ggfls. als neue Kategorie
  • Alexander: KDV-Anbindung und Nutzung der Kundennummern in der EVU-SST und Portal sind fachlich noch zu klären. Danach wird es ggfls. ADR-Bedarf geben.
  • Konstantin: ADR 35 - aufgeschoben, bis Updates zum Service Mesh von CNP (und IFP als PoC) vorliegen.
  • Martin: ADR 36 wird ergänzt um den Status Quo wiederzugeben. Das jetzige Vorgehen ist voraussichtlich mit MoQ-AP kompatibel.
  • ADR 37 ist relevant für PI 20 wegen CIB-404 Integration und zwar schon ab Sprint 1

3 complete Bing und Annette arbeiten am ADR. → bis zum nächsten Termin 9. April

  • Konstantin: Stammdaten-Bereitstellung für EVUs ist zwar in der EVU-SST spezifiziert muss aber voraussichtlich überarbeitet werden (liegt aktuell bei Basil). Ideen sind:
  • vereinfachte REST-API 
  • "Standard" basierend auf https://de.wikipedia.org/wiki/RailML
  • Monitoring und Überwachung.
  • wird erstmal bei CoP CI/CD vorgestellt.
  •  Namespaces und Umgebungen. Ist- und Ziel-Zustand mit Namen unserer K8s-Namespaces und Bestellsystem-Deployments. (vgl.  und Umgebungskonfiguration)
  • Auch das ist ein Thema für CI/CD
  • Bing: Funktionsumfang und Einsatzgebiet des IFP-Mocks sind zu entscheiden. Insbesondere die Frage, ob er in SpringBoot-Integration-Tests in Steuerung-Vertrieb eingesetzt werden soll.

4 complete Team CIB bereitet eine Entscheidung vor.

Termin am 12.03.2021

Methodisches

  • Workflow für Architekturentscheidungen (siehe hier)
  • Architekturreflexion kommt später

Besprochene ADRs

    1. Identity und Access Management für Portalbenutzer
  • Bis auf externe Abhängigkeiten/Klärung des Betreibers des OIDC-Providers offen
  • Uns fehlt noch Know-How beim Thema Keycloak
  • Frank kann unterstützen
  • Alternativ kann man auch mit IDBF sprechen
  • TODO Konstantin: ADR akzeptiert
    1. Bereitstellung der EVU-Schnittstelle im Internet über gemanagte Web Application Firewall
  • eigentlich fertig und kann in BS-34 umgesetzt werden
  • Testbarkeit ist gewährleistet, konkrete Umsetzung in BS-34 zu berücksichtigen
  • TODO: Martin Eigenes Proxy voraussichtlich notwendig für Tests → als Konsequenz nachpflegen
  • TODO: Konstantin ADR schließen 

Sonstiges

  • Datenmodell für das Bestellportal
  • Wiederverwendung von TDM oder das bisherige? (vgl. BS-176)
  • Plan: 404 mappt von TDM auf das Portal-Datenmodell in Portal-Middleware → kein dringender Diskussionbedarf
  • Martin/CIB: steuerung-vertrieb hätte gerade gerne persistenten Datei-Speicher=>es geht hierbei um den Konstruktions-Mock, somit kein "echtes" Architektur-Thema
Reference in New Issue View Git Blame Copy Permalink