Files

T

ankn a5f8fb49ab Migrate all repos into monorepo context folders

Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
      Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
      Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)

Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.

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

6.5 KiB

Raw Blame History

Fokusthema: Umgebungsmanagement (Team 1)

Version: 20 | Last modified: 2025-08-22T10:49:23.649+02:00 Source: confluence page ID 449094070

Ziele / AgendaAusgangssituationBegriffe Umgebungen & Umgebungsmanagement pro stagewelche mocks, welche tests, aws services, umgebung pro QualitÃ¤tsstufe,Â stehende umgebung oder wegwerf umgebung, artifactory, datenqualitÃ¤t

Tests Was sagt C2S-Plattform und TTT

Aktuelle Probleme Was sind unsere Erwartungen an ein Zielbild Zielbild mit Orientierung an C2S-Plattform und TTT AppendixWarum mocken wir

Ausgangssituation

Begriffe (orientierung an Zielbild TTT) Begriff | ErklÃ¤rung | Preprd | dev, iat, abn | Prod | prod | Quality Coach | Ziel: pro teamÂ teamÃ¼bergreifende Anforderungen aus Sicht des TestingsÂ steuern aktuell nicht bekannt | Systemtest / Systemintergrationstest | Durchlauf (happy-path) vonÂ einem Camunda "Gesamt"-Workflow (z.B. KNK_gesamt) Mock von ART-Fremdsystemenverwendung von mocks nach neuer Definition sieheÂ verwendung keiner mocks nach bisheriger definition sieheÂ Testarchitektur

Werkzeuge: Thunderclient (,Manuelle Usertasks) | Integrationstest | Integrationstests evaluieren, wie verschiedene Komponenten miteinander interagieren. Ziel ist es, sicherzustellen, dass die Schnittstellen korrekt funktionieren und dass die Integration der Module reibungslos verlÃ¤uft.

Werkzeuge: Thunderclient, Robotframework | GeschÃ¤ftsprozesstest | Haben wir das Ã¼berhaupt oder ist das nicht unter Systemtest zu finden? definiert hier https://kuk.gitpages.tech.rz.db.de/doc/architektur/07-test/01-test-concept.html | E2E-Tests (=realisiert durch GeschÃ¤ftsprozesstests z.B. auf kut) | Haben wir das Ã¼berhaupt oder ist das nicht unter Systemtest zu finden? Unterschied zu GeschÃ¤ftsprozess tests: Es wird auf Datenkorrektheit geprÃ¼ft (z.B. PrÃ¼fen Perlschnur zu Produktionsauftrat) | Account/Mandant/Tenant | CNP-Mandant (z.B. kuk-dev) siehe https://kuk.gitpages.tech.rz.db.de/doc/architektur/02-arc42/07-deployment-view.html | Stage | QualitÃ¤tsstufe im Entwicklungsprozess: dev, test, abn, prod (oder nur preprd und prod) | Umgebung/Environment | lÃ¤uffÃ¤higen Softwareverbund mit einem Zweck/Tag Aktuell haben wir immer exakt 1 Umgebung fÃ¼r 1 Stage | Cluster | Technische Laufzeitumgebung mit einem Rechnerpool fÃ¼r mehrere Umgebungen (einer stage) | Service | WebApplikation (kein einmaliger cron-job) | Release | fachliches Release: technisches Release: prozess:Â | Deployment | |

welche mocks, welche tests, aws services, umgebung pro QualitÃ¤tsstufe, stehende umgebung oder wegwerf umgebung, artifactory, datenqualitÃ¤t

probleme: Unsicherheit bezÃ¼glich der Umgebung Unsicherheit bezÃ¼glich konkret der dev Umgebung gerade richtung abn Wollen wir mehr umgebung haben wo machen wir lup und systemtest art-fremde apps mocken camunda mocken2 sichteninprohub will gesamtprozess testen andere apps wollen teilprozess testen

prozessmocks umgebung = namespace â nein umgebung = controlplane oder umgebung = namespace + eigener nodepool (falls notwendig) (korrektes setzen von affinities, taints, tolerations notwendig) stage = cnp tenant service kommunikation nur zwischen services auf einer envservices verknÃ¼pfen mit anderen services auf anderen env's wegen verschiedener datenqualitÃ¤tart-intern: motivation: von dev auf iat da bessere datenqualitÃ¤t Gegenargument: eher daran arbeiten datenqualitÃ¤t auch auf z.B. dev zu erhÃ¶hen, kÃ¶nnte evt. zu verwirrung im art fÃ¼hren art-extern: kontrolle nicht bei uns

schauen das dev auch anspruch das stabil ist (nicht perma down) mocks vs proxiesproxies > mocks fÃ¼r simulation (z.B. von schnittstellen)z.B. Ordnungsrahmen api, kapaguard wenn ids nicht da,

Infrastruktur (aws services)entwicklungsgrad: aws service durch localstack ersetzen kosteneffizient: weniger ressourcen pro z.B. ec2, spot instances > normale instancen (muss nicht bei jedem service ) Produktionsgrad:

lup art-Ã¼bergreifend > lup art-intern bezÃ¼glich der abhÃ¤ngigkeiten diskussion lup bleibt offen camunda prozess mockenmotivation: teilprozess pro app durchlaufen Ã¼berbrÃ¼cken der zeit bis wir systemtest haben alle in camunda dev tenant rein deployen wer hat usecase: unterprozess mocken aktuell:2 camunda instances: dev,abndev: 1 tenant pro appmotivation/vorteil: verschiedene prozesse mocken pro app, jedes produkt hat umgebung um seine prozesse zu testen (und andere zu mocken)prozesstests

nachteil: ist eigentlich komponententest auf einer EU (nicht IEU)

abn: 1 tenant iat, abn, prod

zielbildalternativenweiterhin auf dev tenant pro app nur 1 tenant (kuk-dev) 1 tenant fÃ¼r inprohub und 1 tenant fÃ¼r alle anderen

frage: ist dev eine EU oder IEUEU hab ich ja schon lokal

Systemtest definieren Integrationstest

https://kuk.gitpages.tech.rz.db.de/doc/architektur/04-runbook/02-architecture-overview.html

Aktuelles (Zielbild) Umgebungsmanagement

6.5 KiB Raw Blame History

Fokusthema: Umgebungsmanagement (Team 1)

6.5 KiB

Raw Blame History