Revisione e promozione

Ambienti persistenti e CI & Review

Crea ambienti condivisi di lunga durata, configura percorsi di revisione CI, esamina gli eventi di merge con prove QA, esegui il merge in Console e promuovi il candidato convalidato.

Amministratori clienteMembri clienteOperatori della piattaforma

Ultimo aggiornamento 26 settembre 2026

Environments (/environments) e CI & Review (/ci-review) sono i flussi di convalida condivisi di Console. Usali quando un team ha bisogno di un runtime QA, UAT, demo, staging o revisione cliente di lunga durata e vuole che le modifiche superino la revisione del codice e il QA prima della promozione.

Un ambiente persistente non è un workspace personale. È un runtime condiviso del team, con criteri, fatturazione e cronologia degli eventi propri. Un profilo workspace CI indica a Console quale runtime di revisione o QA usare quando un evento di merge richiede controlli del browser, del database o di code intelligence.

Chi può vederli

Entrambe le pagine si trovano sotto Distribuisci nella navigazione per chiunque faccia parte di un team: membri e amministratori del team, operatori e amministratori della piattaforma. I criteri del team stabiliscono chi può creare ambienti e profili CI. Se manca il pulsante di creazione o l’operazione viene rifiutata, chiedi a un amministratore del team.

Prima di iniziare

• Collega il provider Git per il repository (Impostazioni → Accesso Git).
• Procurati un backup del database approvato per il seed (Backup).
• Decidi se il percorso deve controllare solo il branch di origine oppure anche usare un ambiente persistente come destinazione. Questa scelta determina quali verifiche vengono eseguite.

Ambienti persistenti

Persistent Environments («Crea e gestisci workspace persistenti per gli ambienti del team») elenca gli ambienti del team, con la coda, i dettagli e l’ispettore. L’icona (i) accanto al titolo spiega la pagina e rimanda a questa guida.

Creare un ambiente persistente

Scegli Create environment (/environments/new). La procedura guidata contiene quattro passaggi, Origine, Runtime, Policy e Revisione, oltre a un pannello di avvio che elenca gli eventuali blocchi ancora presenti.

1. Origine: il team, il nome dell’ambiente, l’URL del repository e il branch di origine. Console controlla l’accesso del provider. Attiva lo stack di repository quando un repository runtime e uno di prodotto devono essere estratti in sequenza.
2. Runtime: il profilo dell’ambiente persistente, la famiglia di template, la destinazione e le dimensioni del workspace. Il profilo definisce la versione di WebCentral (Java, Gradle, Tomcat e bundle della licenza).
3. Policy: il backup seed, l’esposizione e il motore di migrazione del database (Flyway, ARCHIBUS DUW oppure nessuno).
4. Revisione: controlla il piano, quindi scegli Create environment. Qui viene mostrato il prezzo di disponibilità per la durata selezionata.

Console crea il record e avvia il workspace di supporto. L’ambiente mostra quindi il workspace persistente, il candidato e le versioni correnti, lo stato di aggiornamento, le scorciatoie runtime e la cronologia degli eventi. Chiunque possa vedere un ambiente può rinominarlo tramite il controllo a forma di matita. La rinomina modifica solo il nome visualizzato.

Scorciatoie runtime

Aggiornare un ambiente in due fasi

Un ambiente condiviso non viene mai riavviato per errore:

1. Request environment update approva l’aggiornamento, ma non interviene ancora sull’ambiente in esecuzione.
2. Start environment update lo avvia e ne attende il completamento. Lo stato passa a in esecuzione e poi ad applicato.

CI & Review

CI & Review («Segui gli eventi di merge dall’intake all’approvazione, al QA nel workspace, alla convalida dell’ambiente di destinazione e al merge umano») è il luogo in cui le modifiche vengono esaminate e unite. L’icona (i) accanto al titolo spiega la pagina e rimanda a questa guida.

Una sequenza del flusso di lavoro mostra le fasi dell’evento di merge selezionato: Intake, Review, QA, Target QA e Merge. Sotto ci sono cinque schede, ciascuna con il proprio conteggio:

Creare un profilo workspace CI

Scegli Create CI profile (/ci-review/workspaces/new). I passaggi sono Source route, Workspace runtime, Run policy e Review and create.

1. Source route: team, provider, repository, branch e, facoltativamente, ambiente di destinazione. Un ambiente di destinazione attiva il controllo della destinazione.
2. Workspace runtime: revisione, QA, revisione più QA oppure QA di destinazione, oltre a template CI, destinazione e dimensioni.
3. Run policy: conservazione, artefatti, fasi da eseguire, ambito del QA, motore di migrazione, profilo della versione WebCentral e backup del database.
4. Review and create: controlla la griglia, quindi scegli Create CI profile.

Un profilo contiene metadati del percorso, non un workspace personale. Console lo usa quando un evento di merge richiede un workspace di revisione o QA.

Configurare il passaggio al provider

In Provider handoff, carica un percorso, quindi:

• Salva una connessione gestita usando un riferimento di credenziale approvato. Console mostra solo un’anteprima dopo il salvataggio.
• Rotate credential o Revoke credential.
• Install webhook, Reconcile webhook o Remove webhook.
• Check connection prima di affidarti al percorso.

Non inserire mai token del provider nei nomi dei percorsi, nelle descrizioni o nelle note QA.

Revisione dell’implementazione

La revisione dell’implementazione è il processo che trasforma una modifica pianificata, spesso un issue approvato in Design, in codice unito:

1. Uno sviluppatore implementa l’issue in un workspace e invia un branch.
2. La modifica arriva in Merge events tramite webhook del provider, passaggio dal workspace o registrazione manuale.
3. In Revisione, controlla i branch di origine e destinazione, il collegamento al provider, i revisori e le modifiche in stack. Assegna revisori e aggiungi note.
4. Scegli Start review & QA. La revisione ArchiBot esamina il codice, le differenze in stack, i test mancanti e i percorsi rischiosi. Il QA del runner raccoglie prove di esecuzione: test smoke del browser, controlli del database, comandi di test e log del workspace. Consulta Console Bots.
5. Segui la sequenza del flusso di lavoro e Run detail. Usa Annulla esecuzione per interrompere un’esecuzione.

Merge in Console diventa disponibile solo quando:

• è registrata l’approvazione di un revisore;
• la revisione del codice richiesta è superata;
• il QA del runner richiesto è superato; e
• se è selezionato un ambiente di destinazione, il relativo controllo è superato.

Il merge umano è l’impostazione predefinita. Dopo il merge, il candidato può essere promosso: in Environments usa Promote candidate quando l’ultima esecuzione corrisponde al candidato, quindi applica l’aggiornamento in due fasi descritto sopra.

Solo branch sorgente oppure ambiente di destinazione

Senza un ambiente di destinazione, Console esegue la revisione del codice e il QA del runner, mentre Target QA risulta ignorato. Con un ambiente, Console convalida anche il candidato rispetto al database, al backup, al motore di migrazione, alla destinazione, al template, alla toolchain e ai parametri di quell’ambiente prima del merge o della promozione. Usa lo stesso profilo versione WebCentral nell’ambiente e in entrambi i profili QA.

Log e prove

Salva in Shared Drive conserva le prove oltre il normale periodo di conservazione dei log. Serve un drive scrivibile. Prima del merge, i revisori dovrebbero poter capire da Console cosa è cambiato, quali controlli sono stati eseguiti e dove si trovano le prove sanitizzate. Non condividere mai chiavi, token del provider, cookie, segreti del cluster, URL di database, contenuti di backup o file di licenza.

Su un telefono

• Environments dispone in colonna la coda, i dettagli e l’ispettore. Selezionando un ambiente, i relativi dettagli vengono portati in vista.
• Create environment e Create CI profile restano fissati in fondo allo schermo durante la procedura guidata. I pulsanti duplicati nel pannello di avvio e nella scheda di revisione sono nascosti, così c’è un solo pulsante principale.
• La tabella dei provider CI nella procedura guidata del profilo diventa un insieme di schede con etichette.
• Le schede CI & Review scorrono lateralmente e i link a revisori, esecuzioni e merge request hanno aree di tocco ampie.
• Log di compilazione e le altre finestre di dialogo si aprono come pannelli a tutta larghezza. Il popup (i) accanto a ciascun titolo si adatta allo schermo.

Risoluzione dei problemi

Per il supporto, indica il team, il nome dell’ambiente, l’evento di merge o l’ID dell’esecuzione, i branch, la fase bloccata e un errore sanitizzato. Consulta Passaggio al supporto.

Guide correlate

• Design
• Console Bots
• Centro operazioni
• Shared Drive