Review en automatisering

Persistente omgevingen en CI-review

Maak gedeelde persistente omgevingen met de wizard van vier stappen, stel CI-werkruimteprofielen in, beoordeel merge-gebeurtenissen over de vijf CI-tabbladen en promoot gevalideerde kandidaten vanuit Console.

KlantbeheerdersPlatformoperators

Laatst bijgewerkt 18 juni 2026

Persistente omgevingen en CI-review zijn door Console beheerde workflows voor gedeelde validatie. Gebruik ze wanneer een klant een langlevende QA-, UAT-, demo-, staging- of klantreviewruntime nodig heeft en wil dat wijzigingen de codereview en QA doorstaan voordat ze worden gepromoveerd.

Deze workflows verschillen van persoonlijke ontwikkelaarswerkruimtes. Een persistente omgeving is een gedeelde klantruntime met beleid, facturering, support en gebeurtenisgeschiedenis. Een CI-werkruimteprofiel is een route-eigendomsprofiel voor review- of QA-runtime dat Console gebruikt wanneer een merge-gebeurtenis browser-, database-, code-intelligence- of doelomgevingscontroles nodig heeft.

Beide oppervlakken bevinden zich in de linkerbalk van Console. Omgevingen bezit de gedeelde runtimes en hun kandidaten; CI en review bezit de routes, merge-gebeurtenissen, runs en de overdracht naar de provider. De twee zijn met elkaar verbonden, zodat je tussen een omgeving en de reviewgeschiedenis kunt schakelen zonder context te verliezen.

Voordat je begint

• Je hebt een rol als klantbeheerder of platformoperator nodig om omgevingen en CI-profielen te maken.
• De repository en branch die je wilt valideren, moeten bereikbaar zijn via een verbonden Git-provider. Zie Klantbeheerder instellen voor de providerverbinding en Back-ups en herstelbronnen voor database-seeds.
• Beslis of de route alleen op de bronbranch is of een persistente omgeving als doel heeft, want die keuze verandert welke controles worden uitgevoerd.

Een persistente omgeving maken

Open Omgevingen en selecteer Omgeving maken. Console opent een wizard van vier stappen met een stappenbalk bovenaan: Bron, Runtime, Beleid en Review. Een live startpaneel aan de rechterkant toont de huidige selecties en somt vereiste items op die nog blokkeren.

1. Bron. Kies het klantbereik, geef de omgeving een naam en bevestig de repository-URL en bronbranch. Console verifieert hier de providertoegang. Wanneer een wijziging van meer dan één repository afhangt, schakel je de repository-stack in zodat een runtime-repository en een productrepository in volgorde worden uitgecheckt.
2. Runtime. Kies het persistente-omgevingsprofiel, de templatefamilie, het werkruimtedoel en de runtimegrootte. Het profiel stelt de WebCentral-versieaannames in, inclusief de verwachte Java-, Gradle-, Tomcat- en licentiebundel voor de ondersteunende werkruimte.
3. Beleid. Stel de seed-bron (databaseback-up), de blootstelling en de databasemigratie-engine in. Kies de migratie-engine die bij het doel past: Flyway, ARCHIBUS DUW of uitgeschakelde migraties.
4. Review. Bevestig het startplan. Het reviewraster vat het profiel, de repositorymodus, de grootte en de databaseback-up samen. Wanneer alles wat vereist is aanwezig is, selecteer je Omgeving maken.

Wanneer het maken start, maakt Console het omgevingsrecord en start het de ondersteunende werkruimte wanneer het geselecteerde doel dit ondersteunt. De omgevingskaart toont dan de persistente werkruimte, kandidaat- en huidige versies, de omgevingsupdatestatus, runtime-snelkoppelingen en gebeurtenisgeschiedenis.

Persistente omgevingen zijn bedoeld om langer aan te blijven dan persoonlijke ontwikkelingswerkruimtes. Kies de runtimegrootte en factureringstermijn bewust, en gebruik de gebeurtenisgeschiedenis om te bevestigen wanneer de ondersteunende werkruimte, de Tomcat-route, de database-seed en de promotiestatus klaar zijn.

Gebruik het WebCentral-versieprofiel dat bij de bronrepository of WAR past, vooral voor oudere WebCentral-versies die Tomcat 8.5 of Tomcat 9 nodig hebben in plaats van de huidige standaard. Zie Werkruimte-presets om te zien hoe die profielen aan runtime-instellingen worden toegewezen.

Runtime-snelkoppelingen van de omgeving openen

Nadat de persistente werkruimte bestaat, gebruik je de acties op de omgevingskaart:

Plak geen ruwe logboeken in supporttickets. Deel in plaats daarvan de zichtbare status, het run-ID, de werkruimtenaam, het tijdstempel en de opgeschoonde fouttekst.

Een omgevingsruntime in twee fasen bijwerken

Wanneer een kandidaatversie klaar is om op de persistente runtime te landen, gebruikt Console een bewuste update in twee fasen, zodat een gedeelde omgeving nooit per ongeluk opnieuw wordt gestart.

1. Omgevingsupdate aanvragen. Dit keurt de update voor de persistente werkruimte goed en markeert deze als aangevraagd. Console toont dat de update klaar is om te starten, maar de draaiende omgeving nog niet heeft aangeraakt.
2. Omgevingsupdate starten. Dit start de update van de persistente werkruimte en wacht op het runtimeresultaat. Console verplaatst de status naar draaiend en vervolgens naar toegepast zodra de persistente runtime op de gepromoveerde versie staat.

De omgevingskaart toont de huidige updatestatus en een korte beschrijving voor elke fase, plus runtime-bewijsregels zodat je kunt bevestigen wat er is gewijzigd.

Een CI-werkruimteprofiel maken

Open CI en review en selecteer CI-profiel maken (het is CI/profiel maken in de bovenste actiebalk). Console opent een wizard van vier stappen met dezelfde stappenbalkvorm: Bron, Runtime, Beleid en Review, getoond in het werkgebied als Bronroute, Werkruimteruntime, Uitvoeringsbeleid en Beoordelen en maken.

1. Bronroute. Kies de klant, provider, repository, branch en een optionele doelomgeving. Het selecteren van een doelomgeving is wat de doelcontrole later inschakelt. Pas een repository-stackprofiel toe wanneer de wijziging een runtime-repository plus een product- of afhankelijkheidsrepository nodig heeft.
2. Werkruimteruntime. Kies de vorm van de werkruimte: review, QA, review plus QA, of doel-QA. Selecteer het CI-template, het werkruimtedoel en de grootte.
3. Uitvoeringsbeleid. Stel de retentie, artefacten, welke fasen worden uitgevoerd, de QA-scope en de databasemigratie-engine in. Selecteer het WebCentral-versieprofiel en de databaseback-up. Review gebruikt meestal hoge redenering; QA gebruikt meestal lage redenering nadat deterministische controles bewijs hebben verzameld.
4. Beoordelen en maken. Bevestig het routeprofiel in het reviewraster en selecteer vervolgens CI-profiel maken.

Het opslaan van een CI-werkruimteprofiel maakt geen persoonlijke ontwikkelaarswerkruimte. Het maakt de routemetadata die Console gebruikt wanneer een merge-gebeurtenis of testrun een review- of QA-werkruimte nodig heeft. Lichtgewicht runs kunnen nog steeds de Console-runner zonder werkruimte gebruiken wanneer browser-, database- en code-intelligence-tools niet vereist zijn.

Als de route geen persistente doelomgeving heeft, kan Console nog steeds QA op de bronbranch uitvoeren. De codereview begint vanuit een Console-merge-gebeurtenis, een provider-pull request of een expliciete diff zodat reviewers de werkelijke wijzigingsset en de merge-gate zien. De doelomgevingscontrole wordt overgeslagen omdat er geen omgevingsconfiguratie is om tegen te valideren.

De vijf CI- en reviewtabbladen

Het werkgebied van CI en review is georganiseerd in vijf tabbladen boven het hoofdpaneel, elk met een live telling:

Boven de tabbladen toont een workflowstrook de fase-pipeline voor de geselecteerde merge-gebeurtenis: Intake, Review, QA, Doel-QA en Merge. Elke fase toont zijn eigen status, zoals open, wachtend, overgeslagen of wachtend op controles.

Alleen bronbranch versus doelomgeving

Routes die alleen op de bronbranch zijn, voeren codereview en runner-QA uit zonder een geselecteerde persistente omgeving. In die modus slaat Console opzettelijk de doelomgevingscontrole over, en de fase Doel-QA wordt als overgeslagen getoond.

Routes met een geselecteerde persistente omgeving voegen een doelomgevingscontrole toe. Nadat codereview en runner-QA zijn geslaagd, valideert Console de kandidaat tegen de standaardwaarden van de geselecteerde omgeving voordat de merge of promotie kan doorgaan.

De doelomgevingscontrole gebruikt de omgevingsstandaardwaarden die er na promotie toe doen, waaronder databasetype, databaseback-up, migratie-engine, werkruimtedoel, template, toolchain, werkruimteparameters en licentie-override indien geconfigureerd.

Wanneer een route een oudere WebCentral-versie gebruikt, houd dan hetzelfde versieprofiel aan op de persistente omgeving, het bron-QA-profiel en het doel-QA-profiel. Daardoor draaien het reviewbewijs, de browser-smoketests en de uiteindelijke promotiecontrole op dezelfde runtime-aannames.

De provideroverdracht instellen

Open het tabblad Provideroverdracht en laad een route om de beheerde providerverbinding te registreren of te controleren. Console bezit de reviewlaag; met de providerverbinding kan het review- en QA-opmerkingen plaatsen, statusfeedback verzenden en merge-gebeurtenissen ontvangen.

Vanuit dit tabblad kun je:

• Een beheerde verbinding opslaan. Registreer de provider-app, de service hook of een goedgekeurde referentieverwijzing zoals token://..., k8s://secret/key, of een OpenBao/Vault-verwijzing. Console kan ook een eenmalig providertoken of app-wachtwoord accepteren en het opslaan in de Console-tokenopslag, een Kubernetes Secret of OpenBao/Vault. Na het opslaan toont Console alleen een referentievoorbeeld.
• De referentie roteren. Gebruik Referentie roteren wanneer een token verloopt of wordt vervangen. Voer daarna een verbindingscontrole uit.
• De referentie intrekken. Gebruik Referentie intrekken om het verbindingsrecord te behouden, maar het plaatsen te stoppen totdat een nieuwe referentieverwijzing wordt toegevoegd.
• Een webhook installeren of afstemmen. Gebruik Webhook installeren zodat merge-gebeurtenisupdates Console bereiken, Webhook afstemmen om een afgedwaalde hook te repareren en Webhook verwijderen om gebeurtenissen te stoppen. Sla een route op of selecteer deze voordat je de webhook installeert.
• De verbinding controleren. Gebruik Verbinding controleren om de gezondheid te bevestigen voordat je op de route vertrouwt voor review, status of het plaatsen van opmerkingen.

Een gereedheidspaneel doorloopt de routemetadata, de providerservice, het installatiedoel, de referentiebron, de toegestane acties, het Console-record en de providergezondheid, zodat je kunt zien welke stap nog ontbreekt.

Plaats geen providertokens, ruwe referentiepayloads of privé-deploymentgeheimen in routenamen, beschrijvingen, QA-notities of route-instructies.

Een merge-gebeurtenis beoordelen

Merge-gebeurtenissen zijn de normale reviewunit in Console. Een merge-gebeurtenis kan afkomstig zijn van een providerwebhook, een werkruimteoverdracht of handmatige Console-registratie.

1. Open CI en review.
2. Kies de merge-gebeurtenis op het tabblad Merge-gebeurtenissen.
3. Open Review in Console om de bronbranch, doelbranch, providerlink, feature-items, reviewerslijst en gestapelde wijzigingen te zien.
4. Wijs reviewers toe of voeg een aangepaste reviewer toe, en werk de reviewersnotities bij.
5. Selecteer Review en QA starten wanneer de route klaar is.
6. Bekijk de workflowstrook: Intake, Review, QA, Doel-QA en Merge.

Wanneer gestapelde wijzigingen worden gedetecteerd, toont Console het begrensde stackvoorbeeld en de per-bestandcontext die het veilig kan weergeven. Gebruik providerlinks alleen voor secundaire context.

Archibot-review en runner-QA kunnen afzonderlijk of samen worden uitgevoerd. Review richt zich op code, gestapelde diff-context, ontbrekende tests, riskante paden en documentatie-impact. QA richt zich op uitvoeringsbewijs zoals browser-smoke, databasecontroles, geselecteerde testopdrachten, toolchainvalidatie en werkruimtelogboeken. Zie Console-bots om te zien hoe Archibot-review- en QA-bots worden geconfigureerd.

Als een run moet stoppen, gebruik dan Run annuleren op de run op het tabblad Bewijs en logboeken. Console markeert de run als geannuleerd.

Mergen en promoveren

Console houdt menselijke merge als standaard.

Voordat Merge in Console beschikbaar is:

• Een reviewergoedkeuring moet zijn vastgelegd.
• De aangevraagde codereviewfase moet slagen.
• De aangevraagde runner-QA-fase moet slagen.
• Als een doelomgeving is geselecteerd, moet de doelomgevingscontrole slagen.

Nadat de merge is voltooid, kan de gevalideerde kandidaat een promotiekandidaat worden voor de geselecteerde persistente omgeving. Gebruik Kandidaat promoveren vanuit Omgevingen alleen wanneer de laatste CI-run en de doelomgevingscontrole overeenkomen met de kandidaatversie. Eenmaal gepromoveerd, gebruik je de hierboven beschreven omgevingsupdate in twee fasen om deze op de draaiende runtime te landen.

Logboeken, bewijs en Shared Drive

CI en review en Omgevingen houden de gebeurtenisgeschiedenis bij in Console. Gebruik de runtijdlijn op het tabblad Bewijs en logboeken om fasewijzigingen, jobnamen, doelomgevingsstatus en opgeschoonde logregels te zien.

Gebruik Opslaan naar Shared Drive wanneer support bewijs nodig heeft dat het normale retentievenster van runlogboeken overleeft. Het account heeft hiervoor een beschrijfbare schijf nodig. Houd langlevend bewijs opgeschoond en door de klant goedgekeurd. Zie Werkruimte-Archibot en Shared Drive om te zien hoe toegang tot een schijf met bereik werkt.

Reviewers zouden vóór het mergen drie vragen vanuit Console moeten kunnen beantwoorden:

• Wat is er gewijzigd, inclusief eventuele gestapelde diffs?
• Welke review-, QA- en doelcontroles zijn uitgevoerd?
• Waar is het opgeschoonde bewijs als de run later supportreview nodig heeft?

Deel niet:

• API-sleutels, providertokens, webhookgeheimen, cookies of uitnodigingslinks.
• Kubernetes Secrets, pod-omgevingsvariabelen, kubeconfigs of Coder-tokens.
• Ruwe database-URL’s, ruwe back-upinhoud of licentiebestanden.
• Privé-transcripties of klantgegevensdumps.

Veelvoorkomende blokkades

Overdracht naar support

Voor support, voeg toe:

• Het klantaccount en de omgevingsnaam.
• Het merge-gebeurtenis-ID of CI-run-ID.
• De bronbranch, doelbranch en het merge request-nummer van de provider indien zichtbaar.
• De fase die geblokkeerd is.
• De opgeschoonde Console-fout of logboeksamenvatting.

Voeg geen ruwe referenties, volledige logboeken met geheimen, privé-databasegegevens of eenmalige links toe. Zie Overdracht naar support voor de volledige bewijschecklist.