Vier Stages: LOCAL, TEST, QS, PROD

Dieses Kapitel beschreibt, wie eine Aenderung an der Novaris-Landschaft von der Entwicklung bis in den (simulierten) Produktivbetrieb wandert - unabhaengig davon, welches Teilsystem betroffen ist.

Die vier Stufen

Stage	Zweck	Wer loest aus	Jenkins-Job?
LOCAL	Entwicklung, Debugging, erste Verifikation	Entwickler, manuell in IntelliJ	Nein - siehe `03-lokale-entwicklung-intellij.md`
TEST	Automatischer Nachweis "baut und laeuft" fuer jeden Commit	jeder Push/jede PR	Ja, automatisch
QS	Fachliche Abnahme vor einer Veroeffentlichung	Freigabe durch QS-Team	Ja, mit manueller Freigabe
PROD	Produktivbetrieb	Freigabe durch Release-Verantwortliche, nur von `main`/`release/*`	Ja, mit manueller Freigabe + Branch-Beschraenkung

Warum LOCAL kein Jenkins-Job ist

LOCAL ist bewusst kein automatisierter Pipeline-Schritt - es ist der Zustand, in dem ein Entwickler an seinem eigenen Rechner arbeitet, mit den in Phase 5 aufgebauten Werkzeugen (novaris-integration-tests gegen selbst gestartete Docker-Container, liberty-verify gegen den eigenen Rechner). Eine Pipeline dafuer waere sinnlos - es gibt keinen "Build" im CI-Sinne, den ein Server auf Zuruf ausloesen muesste; der Entwickler fuehrt die Schritte selbst und interaktiv aus. Siehe 03-lokale-entwicklung-intellij.md.

Der Promotion-Flow

Commit/Push
    |
    v
[Build] -> [Unit-/Modultests + Coverage] -> [Package] <- passiert IMMER, jeder Branch
    |
    | DEPLOY_STAGE >= test
    v
[Deploy TEST]                                    <- automatisch
    |
    | DEPLOY_STAGE >= qs
    v
[Freigabe QS] (manuell) -> [Deploy QS]
    |
    | DEPLOY_STAGE == prod UND Branch main/release/*
    v
[Freigabe PROD] (manuell) -> [Deploy PROD]

Der Parameter DEPLOY_STAGE (siehe Jenkinsfile) legt fest, wie weit eine konkrete Pipeline-Ausfuehrung ueberhaupt gehen SOLL - none bedeutet "nur Build+Test", ohne dass ueberhaupt versucht wird, irgendwo zu deployen. Das ist der Normalfall fuer Pull-Request- Builds: man will wissen, ob der Code baut und die Tests bestehen, ohne dass automatisch irgendetwas deployt wird.

Der Legacy-Jenkinslauf verwendet standardmaessig mvn -Pcoverage verify. Die echten Oracle-/IBM-MQ-Tests werden mit RUN_INTEGRATION_TESTS separat zugeschaltet, weil sie Docker, Zugangsdaten und externe Infrastruktur benoetigen. Der moderne Jenkinslauf baut zusaetzlich die React-SPA und ihre vier Container-Images.

Die zentrale Jenkins-Instanz kommt aus ../../shared/enterprise-infrastructure/jenkins; Kafka und Keycloak werden lokal ebenfalls ueber ../../shared/enterprise-infrastructure bereitgestellt. Siehe docs/70-migration/15-enterprise-infrastructure.md.

Warum PROD zusaetzlich an den Branch gebunden ist

Die QS-Freigabe pruefte nur "ist ein Mensch einverstanden", nicht "kommt das vom richtigen Branch". Fuer PROD reicht das nicht - ein versehentlicher DEPLOY_STAGE=prod-Lauf auf einem Feature-Branch soll gar nicht erst bis zur Freigabe-Frage kommen. Deshalb prueft die when-Bedingung der PROD-Stages im Jenkinsfile zusaetzlich env.BRANCH_NAME - nur main oder ein release/*-Branch duerfen ueberhaupt die Freigabe-Stage erreichen. Das ist derselbe Gedanke wie die Rollen-Trennung auf EJB-Ebene (@RolesAllowed, siehe docs/10-ejb-konzepte/01-session-beans.md) - Berechtigungen werden auf mehreren, sich ergaenzenden Ebenen durchgesetzt, nicht nur an einer Stelle.

Zugangsdaten: nie in Dateien, immer im Credentials-Store

ci/env/*.properties enthaelt bewusst keine Passwoerter - nur unkritische Konfigurationswerte (Hostnamen, Ports, Datenbanknamen). Passwoerter kommen ausschliesslich aus dem Jenkins-Credentials-Store und werden per withCredentials(...) im Jenkinsfile zur Laufzeit als Umgebungsvariablen injiziert, mit genau den Namen, die server.xml bereits erwartet (NOVARIS_ORACLE_PASSWORD, NOVARIS_DB2_PASSWORD, ...) - siehe 02-jenkinsfile-erklaert.md.

⌂ Cockpit