Review und Automatisierung

Persistente Umgebungen und CI-Review

Erstellen Sie gemeinsame persistente Umgebungen mit dem vierstufigen Assistenten, richten Sie CI-Workspace-Profile ein, prüfen Sie Merge-Ereignisse über die fünf CI-Registerkarten und befördern Sie validierte Kandidaten aus Console.

KundenadministratorenPlattformbetreiber

Zuletzt aktualisiert 18. Juni 2026

Persistente Umgebungen und CI-Review sind von Console verwaltete Workflows für die gemeinsame Validierung. Verwenden Sie sie, wenn ein Kunde eine langlebige QA-, UAT-, Demo-, Staging- oder Kundenreview-Laufzeit benötigt und möchte, dass Änderungen die Code-Review und QA bestehen, bevor sie befördert werden.

Diese Workflows unterscheiden sich von persönlichen Entwickler-Workspaces. Eine persistente Umgebung ist eine gemeinsame Kunden-Laufzeit mit Richtlinien, Abrechnung, Support und Ereignisverlauf. Ein CI-Workspace-Profil ist ein routen-verwaltetes Review- oder QA-Laufzeitprofil, das Console verwendet, wenn ein Merge-Ereignis Browser-, Datenbank-, Code-Intelligence- oder Zielumgebungsprüfungen benötigt.

Beide Oberflächen befinden sich in der linken Leiste von Console. Umgebungen verwaltet die gemeinsamen Laufzeiten und ihre Kandidaten; CI und Review verwaltet die Routen, Merge-Ereignisse, Läufe und die Provider-Übergabe. Beide sind miteinander verknüpft, sodass Sie zwischen einer Umgebung und ihrem Review-Verlauf wechseln können, ohne den Kontext zu verlieren.

Bevor Sie beginnen

• Sie benötigen eine Kundenadministrator- oder Plattformbetreiber-Rolle, um Umgebungen und CI-Profile zu erstellen.
• Das Repository und der Branch, die Sie validieren möchten, müssen über einen verbundenen Git-Provider erreichbar sein. Siehe Kundenadministrator-Einrichtung für die Provider-Verbindung und Sicherungen und Wiederherstellungsquellen für Datenbank-Seeds.
• Entscheiden Sie, ob die Route nur den Quell-Branch verwendet oder auf eine persistente Umgebung abzielt, denn diese Wahl ändert, welche Prüfungen ausgeführt werden.

Eine persistente Umgebung erstellen

Öffnen Sie Umgebungen und wählen Sie Umgebung erstellen. Console öffnet einen vierstufigen Assistenten mit einer Schrittleiste oben: Quelle, Laufzeit, Richtlinie und Review. Ein Live-Startbereich auf der rechten Seite zeigt die aktuellen Auswahlen und listet alle erforderlichen Elemente auf, die noch blockieren.

1. Quelle. Wählen Sie den Kundenbereich, benennen Sie die Umgebung und bestätigen Sie die Repository-URL und den Quell-Branch. Console überprüft hier den Provider-Zugriff. Wenn eine Änderung von mehr als einem Repository abhängt, aktivieren Sie den Repository-Stack, damit ein Laufzeit-Repository und ein Produkt-Repository der Reihe nach ausgecheckt werden.
2. Laufzeit. Wählen Sie das Profil der persistenten Umgebung, die Vorlagenfamilie, das Workspace-Ziel und die Laufzeitgröße. Das Profil legt die WebCentral-Versionsannahmen fest, einschließlich des erwarteten Java-, Gradle-, Tomcat- und Lizenzbündels für den zugrunde liegenden Workspace.
3. Richtlinie. Legen Sie die Seed-Quelle (Datenbanksicherung), die Exposition und die Datenbank-Migrations-Engine fest. Wählen Sie die Migrations-Engine, die zum Ziel passt: Flyway, ARCHIBUS DUW oder deaktivierte Migrationen.
4. Review. Bestätigen Sie den Startplan. Das Review-Raster fasst Profil, Repository-Modus, Größe und Datenbanksicherung zusammen. Wenn alles Erforderliche vorhanden ist, wählen Sie Umgebung erstellen.

Wenn die Erstellung beginnt, erstellt Console den Umgebungsdatensatz und startet den zugrunde liegenden Workspace, wenn das ausgewählte Ziel dies unterstützt. Die Umgebungskarte zeigt dann den persistenten Workspace, Kandidaten- und aktuelle Versionen, den Umgebungsaktualisierungsstatus, Laufzeit-Verknüpfungen und den Ereignisverlauf.

Persistente Umgebungen sind dafür gedacht, länger aktiv zu bleiben als persönliche Entwicklungs-Workspaces. Wählen Sie die Laufzeitgröße und die Abrechnungsdauer bewusst und nutzen Sie den Ereignisverlauf, um zu bestätigen, wann der zugrunde liegende Workspace, die Tomcat-Route, der Datenbank-Seed und der Beförderungsstatus bereit sind.

Verwenden Sie das WebCentral-Versionsprofil, das zum Quell-Repository oder WAR passt, insbesondere für ältere WebCentral-Versionen, die Tomcat 8.5 oder Tomcat 9 anstelle des aktuellen Standards benötigen. Siehe Workspace-Voreinstellungen, um zu sehen, wie diese Profile auf Laufzeiteinstellungen abgebildet werden.

Laufzeit-Verknüpfungen der Umgebung öffnen

Nachdem der persistente Workspace existiert, verwenden Sie die Aktionen der Umgebungskarte:

Fügen Sie keine Rohprotokolle in Support-Tickets ein. Teilen Sie stattdessen den sichtbaren Status, die Lauf-ID, den Workspace-Namen, den Zeitstempel und den bereinigten Fehlertext.

Eine Umgebungslaufzeit in zwei Phasen aktualisieren

Wenn eine Kandidatenversion bereit ist, auf der persistenten Laufzeit zu landen, verwendet Console eine bewusste zweistufige Aktualisierung, damit eine gemeinsame Umgebung nie versehentlich neu gestartet wird.

1. Umgebungsaktualisierung anfordern. Dies genehmigt die Aktualisierung für den persistenten Workspace und markiert sie als angefordert. Console zeigt, dass die Aktualisierung startbereit ist, aber die laufende Umgebung noch nicht berührt hat.
2. Umgebungsaktualisierung starten. Dies startet die Aktualisierung des persistenten Workspace und wartet auf das Laufzeitergebnis. Console setzt den Status auf laufend und dann auf angewendet, sobald die persistente Laufzeit auf der beförderten Version ist.

Die Umgebungskarte zeigt den aktuellen Aktualisierungsstatus und eine kurze Beschreibung für jede Phase sowie Laufzeit-Belegzeilen, damit Sie bestätigen können, was sich geändert hat.

Ein CI-Workspace-Profil erstellen

Öffnen Sie CI und Review und wählen Sie CI-Profil erstellen (in der oberen Aktionsleiste ist es CI/Profil erstellen). Console öffnet einen vierstufigen Assistenten mit derselben Schrittleisten-Form: Quelle, Laufzeit, Richtlinie und Review, im Arbeitsbereich angezeigt als Quellroute, Workspace-Laufzeit, Laufrichtlinie und Überprüfen und erstellen.

1. Quellroute. Wählen Sie den Kunden, Provider, das Repository, den Branch und eine optionale Zielumgebung. Die Auswahl einer Zielumgebung aktiviert später die Zielprüfung. Wenden Sie ein Repository-Stack-Profil an, wenn die Änderung ein Laufzeit-Repository plus ein Produkt- oder Abhängigkeits-Repository benötigt.
2. Workspace-Laufzeit. Wählen Sie die Workspace-Form: Review, QA, Review plus QA oder Ziel-QA. Wählen Sie die CI-Vorlage, das Workspace-Ziel und die Größe.
3. Laufrichtlinie. Legen Sie Aufbewahrung, Artefakte, welche Phasen laufen, den QA-Umfang und die Datenbank-Migrations-Engine fest. Wählen Sie das WebCentral-Versionsprofil und die Datenbanksicherung. Review verwendet in der Regel hohes Reasoning; QA verwendet in der Regel niedriges Reasoning, nachdem deterministische Prüfungen Belege gesammelt haben.
4. Überprüfen und erstellen. Bestätigen Sie das Routenprofil im Review-Raster und wählen Sie dann CI-Profil erstellen.

Das Speichern eines CI-Workspace-Profils erstellt keinen persönlichen Entwickler-Workspace. Es erstellt die Routen-Metadaten, die Console verwendet, wenn ein Merge-Ereignis oder ein Testlauf einen Review- oder QA-Workspace benötigt. Leichtgewichtige Läufe können weiterhin den Console-Runner ohne Workspace verwenden, wenn Browser-, Datenbank- und Code-Intelligence-Tools nicht erforderlich sind.

Wenn die Route keine persistente Zielumgebung hat, kann Console weiterhin QA auf dem Quell-Branch ausführen. Die Code-Review beginnt mit einem Console-Merge-Ereignis, einem Provider-Pull-Request oder einem expliziten Diff, sodass Reviewer den tatsächlichen Änderungssatz und das Merge-Gate sehen. Die Zielumgebungsprüfung wird übersprungen, da keine Umgebungskonfiguration zur Validierung vorhanden ist.

Die fünf CI- und Review-Registerkarten

Der CI- und Review-Arbeitsbereich ist in fünf Registerkarten über dem Hauptbereich organisiert, jede mit einem Live-Zähler:

Über den Registerkarten zeigt ein Workflow-Streifen die Phasen-Pipeline für das ausgewählte Merge-Ereignis: Eingang, Review, QA, Ziel-QA und Merge. Jede Phase zeigt ihren eigenen Status, etwa offen, wartend, übersprungen oder auf Prüfungen wartend.

Nur Quell-Branch versus Zielumgebung

Routen, die nur den Quell-Branch verwenden, führen Code-Review und Runner-QA ohne ausgewählte persistente Umgebung aus. In diesem Modus überspringt Console absichtlich die Zielumgebungsprüfung, und die Phase Ziel-QA wird als übersprungen angezeigt.

Routen mit einer ausgewählten persistenten Umgebung fügen eine Zielumgebungsprüfung hinzu. Nachdem Code-Review und Runner-QA bestanden haben, validiert Console den Kandidaten gegen die Standardwerte der ausgewählten Umgebung, bevor der Merge oder die Beförderung fortfahren kann.

Die Zielumgebungsprüfung verwendet die Umgebungsstandardwerte, die nach der Beförderung wichtig sind, einschließlich Datenbanktyp, Datenbanksicherung, Migrations-Engine, Workspace-Ziel, Vorlage, Toolchain, Workspace-Parameter und Lizenzüberschreibung, sofern konfiguriert.

Wenn eine Route eine ältere WebCentral-Version verwendet, behalten Sie dasselbe Versionsprofil für die persistente Umgebung, das Quell-QA-Profil und das Ziel-QA-Profil bei. Dadurch laufen Review-Belege, Browser-Smoke-Tests und die abschließende Beförderungsprüfung unter denselben Laufzeitannahmen.

Die Provider-Übergabe einrichten

Öffnen Sie die Registerkarte Provider-Übergabe und laden Sie eine Route, um die verwaltete Provider-Verbindung zu registrieren oder zu prüfen. Console besitzt die Review-Ebene; die Provider-Verbindung ermöglicht es ihr, Review- und QA-Kommentare zu posten, Status-Feedback zu senden und Merge-Ereignisse zu empfangen.

In dieser Registerkarte können Sie:

• Eine verwaltete Verbindung speichern. Registrieren Sie die Provider-App, den Service-Hook oder eine genehmigte Anmeldedaten-Referenz wie token://..., k8s://secret/key oder eine OpenBao/Vault-Referenz. Console kann auch ein einmaliges Provider-Token oder ein App-Passwort akzeptieren und es im Console-Token-Speicher, in einem Kubernetes Secret oder in OpenBao/Vault speichern. Nach dem Speichern zeigt Console nur eine Anmeldedaten-Vorschau.
• Die Anmeldedaten rotieren. Verwenden Sie Anmeldedaten rotieren, wenn ein Token abläuft oder ersetzt wird. Führen Sie anschließend eine Verbindungsprüfung durch.
• Die Anmeldedaten widerrufen. Verwenden Sie Anmeldedaten widerrufen, um den Verbindungsdatensatz zu behalten, aber das Posten zu stoppen, bis eine neue Anmeldedaten-Referenz hinzugefügt wird.
• Einen Webhook installieren oder abgleichen. Verwenden Sie Webhook installieren, damit Merge-Ereignis-Updates Console erreichen, Webhook abgleichen, um einen abgedrifteten Hook zu reparieren, und Webhook entfernen, um Ereignisse zu stoppen. Speichern oder wählen Sie eine Route, bevor Sie den Webhook installieren.
• Die Verbindung prüfen. Verwenden Sie Verbindung prüfen, um den Zustand zu bestätigen, bevor Sie sich für Review, Status oder Kommentar-Posting auf die Route verlassen.

Ein Bereitschaftsbereich führt durch Routen-Metadaten, Provider-Dienst, Installationsziel, Anmeldedaten-Quelle, erlaubte Aktionen, den Console-Datensatz und den Provider-Zustand, sodass Sie sehen können, welcher Schritt noch fehlt.

Geben Sie keine Provider-Tokens, rohen Anmeldedaten-Payloads oder privaten Deployment-Geheimnisse in Routennamen, Beschreibungen, QA-Notizen oder Routenanweisungen ein.

Ein Merge-Ereignis prüfen

Merge-Ereignisse sind die normale Review-Einheit in Console. Ein Merge-Ereignis kann von einem Provider-Webhook, einer Workspace-Übergabe oder einer manuellen Console-Registrierung stammen.

1. Öffnen Sie CI und Review.
2. Wählen Sie das Merge-Ereignis auf der Registerkarte Merge-Ereignisse.
3. Öffnen Sie Review in Console, um den Quell-Branch, Ziel-Branch, Provider-Link, Feature-Elemente, die Reviewer-Liste und gestapelte Änderungen zu sehen.
4. Weisen Sie Reviewer zu oder fügen Sie einen benutzerdefinierten Reviewer hinzu und aktualisieren Sie die Reviewer-Notizen.
5. Wählen Sie Review und QA starten, wenn die Route bereit ist.
6. Beobachten Sie den Workflow-Streifen: Eingang, Review, QA, Ziel-QA und Merge.

Wenn gestapelte Änderungen erkannt werden, zeigt Console die begrenzte Stack-Vorschau und den Kontext pro Datei an, den es sicher anzeigen kann. Verwenden Sie Provider-Links nur für sekundären Kontext.

Archibot-Review und Runner-QA können separat oder zusammen laufen. Die Review konzentriert sich auf Code, gestapelten Diff-Kontext, fehlende Tests, riskante Pfade und Auswirkungen auf die Dokumentation. QA konzentriert sich auf Ausführungsbelege wie Browser-Smoke, Datenbankprüfungen, ausgewählte Testbefehle, Toolchain-Validierung und Workspace-Protokolle. Siehe Console-Bots, um zu sehen, wie Archibot-Review- und QA-Bots konfiguriert werden.

Wenn ein Lauf gestoppt werden muss, verwenden Sie Lauf abbrechen für den Lauf auf der Registerkarte Belege und Protokolle. Console markiert den Lauf als abgebrochen.

Mergen und befördern

Console behält den menschlichen Merge als Standard bei.

Bevor Merge in Console verfügbar ist:

• Eine Reviewer-Genehmigung muss erfasst sein.
• Die angeforderte Code-Review-Phase muss bestehen.
• Die angeforderte Runner-QA-Phase muss bestehen.
• Wenn eine Zielumgebung ausgewählt ist, muss die Zielumgebungsprüfung bestehen.

Nachdem der Merge abgeschlossen ist, kann der validierte Kandidat zu einem Beförderungskandidaten für die ausgewählte persistente Umgebung werden. Verwenden Sie Kandidaten befördern aus Umgebungen nur, wenn der letzte CI-Lauf und die Zielumgebungsprüfung mit der Kandidatenversion übereinstimmen. Nach der Beförderung verwenden Sie die oben beschriebene zweistufige Umgebungsaktualisierung, um ihn auf der laufenden Laufzeit zu landen.

Protokolle, Belege und Shared Drive

CI und Review sowie Umgebungen führen den Ereignisverlauf in Console. Verwenden Sie die Lauf-Zeitleiste auf der Registerkarte Belege und Protokolle, um Phasenänderungen, Jobnamen, Zielumgebungsstatus und bereinigte Protokollzeilen zu sehen.

Verwenden Sie In Shared Drive speichern, wenn der Support Belege benötigt, die das normale Aufbewahrungsfenster für Lauf-Protokolle überdauern. Das Konto benötigt dafür ein beschreibbares Laufwerk. Halten Sie langlebige Belege bereinigt und kundengenehmigt. Siehe Workspace-Archibot und Shared Drive, um zu sehen, wie der bereichsbezogene Laufwerkszugriff funktioniert.

Reviewer sollten vor dem Mergen drei Fragen aus Console beantworten können:

• Was hat sich geändert, einschließlich gestapelter Diffs?
• Welche Review-, QA- und Zielprüfungen wurden ausgeführt?
• Wo befinden sich die bereinigten Belege, falls der Lauf später eine Support-Prüfung benötigt?

Teilen Sie nicht:

• API-Schlüssel, Provider-Tokens, Webhook-Geheimnisse, Cookies oder Einladungslinks.
• Kubernetes Secrets, Pod-Umgebungsvariablen, Kubeconfigs oder Coder-Tokens.
• Rohe Datenbank-URLs, rohe Sicherungsinhalte oder Lizenzdateien.
• Private Transkripte oder Kundendaten-Dumps.

Häufige Blocker

Support-Übergabe

Für den Support fügen Sie hinzu:

• Kundenkonto und Umgebungsname.
• Merge-Ereignis-ID oder CI-Lauf-ID.
• Quell-Branch, Ziel-Branch und Provider-Merge-Request-Nummer, sofern sichtbar.
• Die Phase, die blockiert ist.
• Die bereinigte Console-Fehlermeldung oder Protokollzusammenfassung.

Fügen Sie keine rohen Anmeldedaten, vollständigen Protokolle mit Geheimnissen, privaten Datenbankdaten oder Einmal-Links hinzu. Siehe Support-Übergabe für die vollständige Beleg-Checkliste.