Jenkinsfile und Übergabe an Betrieb/Support

Status: dokumentiert/vorbereitet. Das Jenkinsfile ist syntaktisch vollständig und referenziert ausschließlich real getestete Skripte/Maven-Ziele (siehe 01-skripte-und-liberty-cli.md). Ein tatsächlicher Pipeline-Lauf gegen den Jenkins aus shared/enterprise-infrastructure wurde in dieser Session nicht durchgeführt (keine Notwendigkeit, den gemeinsam genutzten Jenkins für ein einzelnes Lernprojekt zu belegen).

Stage-Modell

Identisches Muster wie in labs/novaris-versicherung-legacy und labs/library-enterprise-platform: ein DEPLOY_STAGE-Auswahlparameter (none|test|qs|prod), PROD zusätzlich an den Branch gebunden (main/release/*) und manuell freigegeben. Angepasst an dieses Projekt:

• "Unit-/Modultests" aus dem Referenz-Namen wurde ersetzt durch "Liberty- Serverstart-Verifikation" — dieses Projekt ist Ops-fokussiert, der eigentliche Nachweis ist ein echter Serverstart mit Health-Check (mvn verify -Pliberty-verify), nicht Fachlogik-Unit-Tests wie bei einer klassischen Java-Anwendung.
• Neue Stage "Security-Smoke-Test" (scripts/ldap-test.sh) — läuft vor jedem Deployment, damit ein LDAP-Ausfall nicht erst mitten im Deployment als kryptischer Liberty-Startfehler auffällt, sondern als klar benannter, früher Pipeline-Schritt.

Andocken an den zentralen Jenkins

Wie in shared/enterprise-infrastructure/README.md beschrieben: kein eigener Jenkins-Server für dieses Projekt. Anbindung entweder über die Jenkins-UI ("New Item" → Pipeline → Git-URL + Pfad zum Jenkinsfile) oder reproduzierbar über shared/enterprise-infrastructure/jenkins/casc.yaml (ein eigener Eintrag unter jobs:, analog zum bestehenden library-platform-pipeline-Job).

Credential: concordia-ldap-bind-password

Das Jenkinsfile erwartet ein Jenkins-Credential mit diesem genauen Namen (Bind-Passwort des LDAP-Admin-Accounts, siehe docs/60-security-lifecycle/02-ldap-registry.md) — in dieser Lernumgebung nicht in Jenkins hinterlegt (kein Jenkins-Job aktiv), deshalb wird CONCORDIA_LDAP_BIND_PASSWORD bei allen manuellen Testläufen dieser Session direkt als Kommandozeilen-Umgebungsvariable gesetzt.

Übergabe an Betrieb/Support: Checkliste

Was ein neu übernehmendes Support-Team über concordia-portal wissen müsste, bevor die Verantwortung übergeben wird — bewusst als Checkliste, weil genau das im echten Bank-Umfeld oft das fehlende Bindeglied ist (Wissen bleibt beim WAS-Admin, der es aufgebaut hat, statt dokumentiert zu werden):

• [ ] Wo läuft der Server, wie wird er gestartet/gestoppt? → docs/10-installation-konfiguration/
• [ ] Welche LDAP-Gruppen mappen auf welche Rollen, wer pflegt das Verzeichnis? → docs/60-security-lifecycle/01-rollen-und-rechte.md
• [ ] Wann läuft das SSL-Zertifikat ab, wer ist für die Rotation zuständig? → docs/60-security-lifecycle/03-zertifikate-ssl.md
• [ ] Welche RACF-ID/DB2-Verbindung wird genutzt, wer beim DB2-for-z/OS-Team ist Eskalationskontakt? → docs/40-bindeglied-dev-ops-db2-netzwerk/02-der-bindeglied-prozess.md
• [ ] Wie zieht man im Störungsfall einen Thread-/Heap-Dump, ohne den Server unnötig neu zu starten? → docs/20-monitoring-tuning/02-heap-und-thread-dumps.md
• [ ] Welche Firewall-Freigaben sind für diesen Server aktiv, wer ist Ansprechpartner beim Netzwerk-Team? → docs/40-bindeglied-dev-ops-db2-netzwerk/03-netzwerksegmentierung.md
• [ ] Wie sieht ein normaler Deployment-Durchlauf aus, was tun bei Fehlschlag? → diese Seite
• 01-skripte-und-liberty-cli.md

Diese Checkliste selbst ist der Kern des Anzeigen-Punkts "Bereitstellung und Administration der Applikationen (inkl. Übergabe an den Betrieb und Support)" — nicht ein einzelnes Tool, sondern die Disziplin, genau diese sieben Fragen für jede Anwendung beantwortbar zu halten.