Revisione e automazione

Ambienti persistenti e revisione CI

Crea ambienti persistenti condivisi con la procedura guidata in quattro passaggi, configura i profili dell'area di lavoro CI, esamina gli eventi di merge nelle cinque schede CI e promuovi i candidati convalidati da Console.

Amministratori clienteOperatori della piattaforma

Ultimo aggiornamento 18 giugno 2026

Gli ambienti persistenti e la revisione CI sono flussi di lavoro di proprietà di Console per la convalida condivisa. Usali quando un cliente ha bisogno di un runtime di QA, UAT, demo, staging o revisione cliente di lunga durata e vuole che le modifiche superino la revisione del codice e il QA prima di essere promosse.

Questi flussi di lavoro sono diversi dalle aree di lavoro personali degli sviluppatori. Un ambiente persistente è un runtime condiviso del cliente con criteri, fatturazione, supporto e cronologia eventi. Un profilo dell’area di lavoro CI è un profilo di runtime di revisione o QA di proprietà di una route, che Console utilizza quando un evento di merge necessita di verifiche di browser, database, code-intelligence o ambiente di destinazione.

Entrambe le superfici si trovano nella barra laterale sinistra di Console. Ambienti possiede i runtime condivisi e i loro candidati; CI e revisione possiede le route, gli eventi di merge, le esecuzioni e il passaggio al provider. Le due sono collegate tra loro, così puoi spostarti tra un ambiente e la sua cronologia di revisione senza perdere il contesto.

Prima di iniziare

• Hai bisogno di un ruolo di amministratore cliente o operatore della piattaforma per creare ambienti e profili CI.
• Il repository e il branch che intendi convalidare devono essere raggiungibili tramite un provider Git connesso. Consulta Configurazione dell’amministratore cliente per la connessione del provider e Backup e fonti di ripristino per i seed del database.
• Decidi se la route è solo sul branch di origine o ha come destinazione un ambiente persistente, perché questa scelta cambia quali verifiche vengono eseguite.

Creare un ambiente persistente

Apri Ambienti e seleziona Crea ambiente. Console apre una procedura guidata in quattro passaggi con una barra dei passaggi in alto: Origine, Runtime, Criterio e Revisione. Un pannello di avvio live a destra mostra le selezioni correnti ed elenca gli elementi richiesti che stanno ancora bloccando.

1. Origine. Scegli l’ambito del cliente, assegna un nome all’ambiente e conferma l’URL del repository e il branch di origine. Console verifica qui l’accesso del provider. Quando una modifica dipende da più di un repository, abilita lo stack di repository in modo che un repository di runtime e un repository di prodotto vengano clonati in ordine.
2. Runtime. Scegli il profilo dell’ambiente persistente, la famiglia di template, la destinazione dell’area di lavoro e la dimensione del runtime. Il profilo imposta le ipotesi sulla versione di WebCentral, incluso il bundle previsto di Java, Gradle, Tomcat e licenza per l’area di lavoro di supporto.
3. Criterio. Imposta la fonte del seed (backup del database), l’esposizione e il motore di migrazione del database. Scegli il motore di migrazione che corrisponde alla destinazione: Flyway, ARCHIBUS DUW o migrazioni disabilitate.
4. Revisione. Conferma il piano di avvio. La griglia di revisione riepiloga il profilo, la modalità del repository, la dimensione e il backup del database. Quando tutto ciò che è richiesto è presente, seleziona Crea ambiente.

Quando inizia la creazione, Console crea il record dell’ambiente e avvia l’area di lavoro di supporto quando la destinazione selezionata lo supporta. La scheda dell’ambiente mostra quindi l’area di lavoro persistente, le versioni candidata e corrente, lo stato di aggiornamento dell’ambiente, le scorciatoie di runtime e la cronologia eventi.

Gli ambienti persistenti sono concepiti per rimanere attivi più a lungo delle aree di lavoro di sviluppo personali. Scegli la dimensione del runtime e il termine di fatturazione in modo deliberato e usa la cronologia eventi per confermare quando l’area di lavoro di supporto, la route Tomcat, il seed del database e lo stato di promozione sono pronti.

Usa il profilo della versione di WebCentral che corrisponde al repository di origine o al WAR, in particolare per le versioni più vecchie di WebCentral che necessitano di Tomcat 8.5 o Tomcat 9 invece del valore predefinito corrente. Consulta Preimpostazioni dell’area di lavoro per vedere come questi profili si mappano alle impostazioni di runtime.

Aprire le scorciatoie di runtime dell’ambiente

Dopo che l’area di lavoro persistente esiste, usa le azioni della scheda dell’ambiente:

Non incollare log grezzi nei ticket di supporto. Condividi invece lo stato visibile, l’ID esecuzione, il nome dell’area di lavoro, il timestamp e il testo dell’errore sanitizzato.

Aggiornare un runtime di ambiente in due fasi

Quando una versione candidata è pronta per atterrare sul runtime persistente, Console usa un aggiornamento deliberato in due fasi in modo che un ambiente condiviso non venga mai riavviato per errore.

1. Richiedi aggiornamento ambiente. Questo approva l’aggiornamento per l’area di lavoro persistente e lo contrassegna come richiesto. Console mostra che l’aggiornamento è pronto per iniziare ma non ha ancora toccato l’ambiente in esecuzione.
2. Avvia aggiornamento ambiente. Questo avvia l’aggiornamento dell’area di lavoro persistente e attende il risultato del runtime. Console sposta lo stato a in esecuzione, poi ad applicato una volta che il runtime persistente è sulla versione promossa.

La scheda dell’ambiente mostra lo stato di aggiornamento corrente e una breve descrizione per ogni fase, oltre a righe di prova del runtime così puoi confermare cosa è cambiato.

Creare un profilo dell’area di lavoro CI

Apri CI e revisione e seleziona Crea profilo CI (è Crea CI/profilo nella barra delle azioni superiore). Console apre una procedura guidata in quattro passaggi con la stessa forma di barra dei passaggi: Origine, Runtime, Criterio e Revisione, mostrati nell’area di lavoro come Route di origine, Runtime dell’area di lavoro, Criterio di esecuzione e Rivedi e crea.

1. Route di origine. Scegli il cliente, il provider, il repository, il branch e un ambiente di destinazione opzionale. La selezione di un ambiente di destinazione è ciò che attiva la verifica di destinazione in seguito. Applica un profilo di stack di repository quando la modifica necessita di un repository di runtime più un repository di prodotto o di dipendenza.
2. Runtime dell’area di lavoro. Scegli la forma dell’area di lavoro: revisione, QA, revisione più QA o QA di destinazione. Seleziona il template CI, la destinazione dell’area di lavoro e la dimensione.
3. Criterio di esecuzione. Imposta la conservazione, gli artefatti, quali fasi vengono eseguite, l’ambito del QA e il motore di migrazione del database. Seleziona il profilo della versione di WebCentral e il backup del database. La revisione di solito usa un ragionamento elevato; il QA di solito usa un ragionamento basso dopo che le verifiche deterministiche hanno raccolto prove.
4. Rivedi e crea. Conferma il profilo della route nella griglia di revisione, quindi seleziona Crea profilo CI.

Il salvataggio di un profilo dell’area di lavoro CI non crea un’area di lavoro di sviluppatore personale. Crea i metadati della route che Console utilizza quando un evento di merge o un’esecuzione di test necessita di un’area di lavoro di revisione o QA. Le esecuzioni leggere possono comunque usare il runner di Console senza un’area di lavoro quando gli strumenti di browser, database e code-intelligence non sono richiesti.

Se la route non ha un ambiente di destinazione persistente, Console può comunque eseguire il QA sul branch di origine. La revisione del codice parte da un evento di merge di Console, una pull request del provider o un diff esplicito così i revisori vedono l’effettivo set di modifiche e il gate di merge. La verifica dell’ambiente di destinazione viene saltata perché non c’è una configurazione di ambiente da convalidare.

Le cinque schede di CI e revisione

L’area di lavoro di CI e revisione è organizzata in cinque schede sopra il pannello principale, ognuna con un conteggio live:

Sopra le schede, una striscia di flusso di lavoro mostra la pipeline delle fasi per l’evento di merge selezionato: Ingresso, Revisione, QA, QA di destinazione e Merge. Ogni fase mostra il proprio stato, come aperta, in attesa, saltata o in attesa di verifiche.

Solo branch di origine rispetto ad ambiente di destinazione

Le route solo sul branch di origine eseguono la revisione del codice e il QA del runner senza un ambiente persistente selezionato. In quella modalità, Console salta intenzionalmente la verifica dell’ambiente di destinazione, e la fase QA di destinazione viene mostrata come saltata.

Le route con un ambiente persistente selezionato aggiungono una verifica dell’ambiente di destinazione. Dopo che la revisione del codice e il QA del runner superano, Console convalida il candidato rispetto ai valori predefiniti dell’ambiente selezionato prima che il merge o la promozione possa procedere.

La verifica dell’ambiente di destinazione usa i valori predefiniti dell’ambiente che contano dopo la promozione, inclusi il tipo di database, il backup del database, il motore di migrazione, la destinazione dell’area di lavoro, il template, la toolchain, i parametri dell’area di lavoro e l’override della licenza quando configurato.

Quando una route usa una versione più vecchia di WebCentral, mantieni lo stesso profilo di versione sull’ambiente persistente, sul profilo QA di origine e sul profilo QA di destinazione. Questo fa sì che le prove di revisione, i test di fumo del browser e la verifica finale di promozione vengano eseguiti con le stesse ipotesi di runtime.

Configurare il passaggio al provider

Apri la scheda Passaggio al provider e carica una route per registrare o verificare la connessione al provider gestito. Console possiede il livello di revisione; la connessione al provider le consente di pubblicare commenti di revisione e QA, inviare feedback sullo stato e ricevere eventi di merge.

Da questa scheda puoi:

• Salvare una connessione gestita. Registra l’app del provider, il service hook o un riferimento di credenziale approvato come token://..., k8s://secret/key, o un riferimento OpenBao/Vault. Console può anche accettare un token del provider monouso o una password dell’app e archiviarlo nell’archivio token di Console, in un Kubernetes Secret o in OpenBao/Vault. Dopo il salvataggio, Console mostra solo un’anteprima della credenziale.
• Ruotare la credenziale. Usa Ruota credenziale quando un token scade o viene sostituito. Esegui successivamente una verifica della connessione.
• Revocare la credenziale. Usa Revoca credenziale per mantenere il record della connessione ma interrompere la pubblicazione finché non viene aggiunto un nuovo riferimento di credenziale.
• Installare o riconciliare un webhook. Usa Installa webhook affinché gli aggiornamenti degli eventi di merge raggiungano Console, Riconcilia webhook per riparare un hook deviato e Rimuovi webhook per interrompere gli eventi. Salva o seleziona una route prima di installare il webhook.
• Verificare la connessione. Usa Verifica connessione per confermare l’integrità prima di affidarti alla route per la revisione, lo stato o la pubblicazione di commenti.

Un pannello di prontezza percorre i metadati della route, il servizio del provider, la destinazione di installazione, la fonte della credenziale, le azioni consentite, il record di Console e l’integrità del provider, così puoi vedere quale passaggio manca ancora.

Non inserire token del provider, payload di credenziali grezze o segreti di distribuzione privati nei nomi delle route, nelle descrizioni, nelle note di QA o nelle istruzioni della route.

Esaminare un evento di merge

Gli eventi di merge sono l’unità di revisione normale in Console. Un evento di merge può provenire da un webhook del provider, da un passaggio dell’area di lavoro o da una registrazione manuale in Console.

1. Apri CI e revisione.
2. Scegli l’evento di merge dalla scheda Eventi di merge.
3. Apri Revisione in Console per vedere il branch di origine, il branch di destinazione, il link del provider, gli elementi della funzionalità, l’elenco dei revisori e le modifiche impilate.
4. Assegna revisori o aggiungi un revisore personalizzato e aggiorna le note del revisore.
5. Seleziona Avvia revisione e QA quando la route è pronta.
6. Osserva la striscia del flusso di lavoro: Ingresso, Revisione, QA, QA di destinazione e Merge.

Quando vengono rilevate modifiche impilate, Console mostra l’anteprima dello stack limitata e il contesto per file che può visualizzare in sicurezza. Usa i link del provider solo per il contesto secondario.

La revisione di Archibot e il QA del runner possono essere eseguiti separatamente o insieme. La revisione si concentra sul codice, sul contesto del diff impilato, sui test mancanti, sui percorsi rischiosi e sull’impatto sulla documentazione. Il QA si concentra sulle prove di esecuzione come i test di fumo del browser, le verifiche del database, i comandi di test selezionati, la convalida della toolchain e i log dell’area di lavoro. Consulta Bot di Console per vedere come sono configurati i bot di revisione e QA di Archibot.

Se un’esecuzione deve fermarsi, usa Annulla esecuzione sull’esecuzione nella scheda Prove e log. Console contrassegna l’esecuzione come annullata.

Eseguire il merge e promuovere

Console mantiene il merge umano come impostazione predefinita.

Prima che Merge in Console sia disponibile:

• Deve essere registrata l’approvazione di un revisore.
• La fase di revisione del codice richiesta deve superare.
• La fase di QA del runner richiesta deve superare.
• Se è selezionato un ambiente di destinazione, la verifica dell’ambiente di destinazione deve superare.

Dopo che il merge è completato, il candidato convalidato può diventare un candidato alla promozione per l’ambiente persistente selezionato. Usa Promuovi candidato da Ambienti solo quando l’ultima esecuzione CI e la verifica dell’ambiente di destinazione corrispondono alla versione candidata. Una volta promosso, usa l’aggiornamento dell’ambiente in due fasi descritto sopra per atterrarlo sul runtime in esecuzione.

Log, prove e Shared Drive

CI e revisione e Ambienti mantengono la cronologia eventi in Console. Usa la cronologia dell’esecuzione nella scheda Prove e log per vedere i cambi di fase, i nomi dei job, lo stato dell’ambiente di destinazione e le righe di log sanitizzate.

Usa Salva su Shared Drive quando il supporto ha bisogno che le prove sopravvivano alla normale finestra di conservazione dei log di esecuzione. L’account ha bisogno di un’unità scrivibile per questo. Mantieni le prove di lunga durata sanitizzate e approvate dal cliente. Consulta Archibot dell’area di lavoro e Shared Drive per vedere come funziona l’accesso all’unità con ambito.

I revisori dovrebbero essere in grado di rispondere a tre domande da Console prima di eseguire il merge:

• Cosa è cambiato, inclusi eventuali diff impilati?
• Quali verifiche di revisione, QA e destinazione sono state eseguite?
• Dove sono le prove sanitizzate se l’esecuzione necessita di revisione del supporto in seguito?

Non condividere:

• Chiavi API, token del provider, segreti del webhook, cookie o link di invito.
• Kubernetes Secrets, variabili d’ambiente del pod, kubeconfig o token di Coder.
• URL del database grezzi, contenuti di backup grezzi o file di licenza.
• Trascrizioni private o dump di dati dei clienti.

Blocchi comuni

Passaggio al supporto

Per il supporto, includi:

• L’account del cliente e il nome dell’ambiente.
• L’ID dell’evento di merge o l’ID dell’esecuzione CI.
• Il branch di origine, il branch di destinazione e il numero della merge request del provider quando visibile.
• La fase che è bloccata.
• L’errore di Console sanitizzato o il riepilogo del log.

Non includere credenziali grezze, log completi con segreti, dati privati del database o link monouso. Consulta Passaggio al supporto per la lista di controllo completa delle prove.