Migrate all repos into monorepo context folders
Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)
Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.
This commit is contained in:
+162
@@ -0,0 +1,162 @@
|
||||
# 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
|
||||
|
||||
Grobteinteilung | preprod | prod |
|
||||
Qualitätsstufe | dev | test | abn | prod |
|
||||
Stage
|
||||
| dev | iat | abn | prod |
|
||||
Umgebung
|
||||
| kuk-dev | kuk-iat | kuk-abn | kuk-prod |
|
||||
Up-Time
|
||||
| 6:00-20:00 | 8:00-20:00 | 8:00-20:00 | durchgängig |
|
||||
SLA
|
||||
| - | - | - | Bronze |
|
||||
KuK Verfahrenscluster | kuk-dev | kuk-iat | kuk-abn | kuk-prod |
|
||||
CNP Cluster | cnp-iat | cnp-iat | cnp-iat | cnp-prod |
|
||||
Camunda Cluster/Instance/Umgebung | cluster-c2s-kuk-dev | cluster-c2s-kuk-dev | cluster-c2s-kuk-abn | cluster-c2s-kuk-abn |
|
||||
Camunda Mandant ID | dev, dev-capaguard, dev-fps,
|
||||
dev-ids, dev-iph, dev-netzlotse-dev-tas
|
||||
| iat | abn | prod |
|
||||
Camunda Modeler | ja
|
||||
| ja | nein | nein |
|
||||
Reifegrad Infrastruktur | Kosteneffizient | Kosteneffizient | Produktionsgrad | Produktionsgrad |
|
||||
Datenbestand | Testdaten | Testdaten | (anonymisierte) prod-daten | prod-daten |
|
||||
Tests | Unit-test | Integrationstests, Systemtests | LuP-Test (ggf. art-übergreifend),
|
||||
E2E/KTU-Tests, Smoke-Tests
|
||||
| Smoke-Tests |
|
||||
Monitoring/Logging | Logging, Monitoring, Alerting
|
||||
| Logging, Monitoring, Alerting | Logging, Monitoring, Alerting | Logging, Monitoring, Alerting |
|
||||
Konnektivität | keine mocks
|
||||
Ausnahmen: BEP, FAPS
|
||||
Proxies?
|
||||
| keine mocks
|
||||
Ausnahme: BEP, FAPS
|
||||
Proxies?
|
||||
| keine mocks | keine mocks |
|
||||
Zielumgebung zur Konnektivität
|
||||
ART-interner Services
|
||||
| kuk-dev
|
||||
| kuk-iat
|
||||
| kuk-abn | kuk-prod |
|
||||
Zielumgebung zur Konnektivität
|
||||
ART-externer Services
|
||||
| kuk-abn
|
||||
| kuk-abn
|
||||
| kuk-abn | kuk-prod |
|
||||
Artifactory Techuser | iat | iat | iat | prod |
|
||||
Artifactory Repository Anbindung | stage | stage | prod | prod |
|
||||
Lebenszyklus Umgebung | stehend | stehend | stehend | stehend |
|
||||
Reference in New Issue
Block a user