Di seguito sono riportate alcune informazioni da sapere prima di configurare ed eseguire i job di build e le pipeline.

• Assicurarsi che le istanze di origine e di destinazione siano della stessa release, con le stesse patch standard e una tantum applicate a entrambi gli ambienti.
• Se è stato configurato il job di creazione package di sviluppo per sovrascrivere la versione dell'applicazione definita in visual-application.json, ottenere la nuova versione. Il processo di packaging della produzione verrà configurato in modo che utilizzi la stessa versione.

Il job di creazione package genera un artifact di estensione pronto per la distribuzione nell'istanza di produzione.

1. Nel Navigator a sinistra, fare clic su Build .
2. Nella scheda Job fare clic su + Crea job.
3. Nella finestra di dialogo Nuovo job, immettere un nome univoco in Nome.
4. In Descrizione, immettere la descrizione del job.
5. In Modello selezionare il modello Valore predefinito di sistema OL7 per Visual Builder.
6. Fare clic su Crea.
7. Fare clic su Configura .
8. Fare clic sulla scheda Git.
9. Nell'elenco Aggiungi Git, selezionare Git.
10. In Repository, selezionare il repository Git. In Diramazione o tag, selezionare il ramo di produzione.
11. Fare clic sulla scheda Steps.
12. In Aggiungi passo, selezionare Estensione applicazione, quindi Pacchetto.
13. Per impostazione predefinita, il passo del packaging riduce il codice sorgente dell'applicazione prima di eseguire la build. Se non si desidera ridurre i file di origine, deselezionare la casella di controllo Ottimizza estensione.

    La minimizzazione è un processo per rimuovere i caratteri non necessari (come spazi vuoti, nuove righe e commenti) dal codice sorgente e ridurre le dimensioni dei file, rendendo il trasferimento dei file richiede meno larghezza di banda e spazio di archiviazione.

    Nota
    
    Quando si deseleziona la casella di controllo Ottimizza estensione, viene visualizzata l'avvertenza seguente: Ottimizzazione non selezionata. Il package senza ottimizzazione può causare problemi di prestazioni. Evitare questa operazione a meno che non si stia eseguendo il debug o la risoluzione dei problemi.
14. (Facoltativo) Se si desidera modificare il nome del file artifact, immettere il nuovo nome in Crea artifact. La procedura consigliata consiste nel mantenere l'impostazione predefinita, extension.vx, ma è possibile modificarla.
    Se la si modifica, è necessario utilizzare il nuovo nome anche nel campo File da archiviare (passo 18) e nel campo Crea artifact del job di distribuzione. Vedere Creazione del job di build della distribuzione di produzione.
15. (Facoltativo) Se il job di packaging di sviluppo è stato configurato in modo da sovrascrivere la versione predefinita dell'estensione definita nel file visual-application.json, specificare la stessa versione in Versione estensione.
16. Fare clic sulla scheda Dopo la generazione nella finestra Configurazione job.
17. In Aggiungi azione dopo generazione, selezionare Archiviatore artifact.
18. In File da archiviare, immettere il nome dell'artifact della build.

    È possibile utilizzare caratteri jolly. Ad esempio, *.vx. Assicurarsi di includere il percorso per l'artifact della build Estensione applicazione.

    Se è stato immesso un valore nel campo Directory di destinazione in Copia artifact per il job di distribuzione, tale valore viene considerato una sottodirectory dell'area di lavoro e deve far parte del percorso dell'artifact nel campo Genera artifact.

19. Se si desidera eliminare i vecchi artifact della build, fare clic su Impostazioni . Nella scheda Generale, selezionare la casella di controllo Elimina vecchie build e specificare le opzioni di eliminazione.
20. Fare clic suSalva.

Il job di distribuzione distribuisce l'artifact dell'estensione generato nel job di packaging nell'istanza di produzione dell'applicazione Oracle Cloud. Prima di creare il job, assicurarsi di disporre delle credenziali che VB Studio può utilizzare per accedere all'istanza PROD dell'applicazione Oracle Cloud.

1. Nel Navigator a sinistra, fare clic su Build .
2. Nella scheda Job fare clic su + Crea job.
3. Nella finestra di dialogo Nuovo job, immettere un nome univoco in Nome.
4. In Descrizione, immettere la descrizione del job.
5. In Modello selezionare il modello Valore predefinito di sistema OL7 per Visual Builder.
6. Fare clic su Crea.
7. Fare clic su Configura .
8. Fare clic sulla scheda Prima della build.
9. In Aggiungi azione prima della generazione, selezionare Copia artifact.
10. In Dal job selezionare il job di creazione package che ha generato l'artifact dell'estensione.
11. In Quale build, selezionare una delle seguenti opzioni:
    • Ultima build riuscita (impostazione predefinita)
    • Build conserva per sempre più recente
    • Build a monte in questa istanza della pipeline
    • Specificata da collegamento permanente
    • Build specifica
    • Specificata dal parametro della build

    A seconda della selezione effettuata, potrebbe essere richiesto di selezionare il parametro permalink, build o build da utilizzare.
12. Lasciare gli altri campi con i relativi valori predefiniti o vuoti.
13. Fare clic sulla scheda Steps.
14. In Aggiungi passo, selezionare Estensione applicazione, quindi Distribuisci.

    Questa immagine mostra la pagina Distribuisci job di build compilata parzialmente.
    
    Descrizione dell'immagine oracle-deploy-build-step.png
    

15. In Istanza di destinazione selezionare l'ambiente con l'istanza di produzione dell'applicazione Oracle Cloud.
16. Nella sezione Autorizzazione, specificare il tipo di autorizzazione per eseguire questo passo della build. Con l'opzione Usa OAuth selezionata per impostazione predefinita, verrà visualizzato il messaggio Authorization is required che indica che questo passo della build richiede un'autorizzazione una tantum per gestire le richieste OAuth all'istanza di Oracle Cloud Applications dell'ambiente in uso. Fare clic su Autorizza e immettere le credenziali per accedere all'istanza di Oracle Cloud Applications. È inoltre possibile eseguire il job manualmente e immettere le credenziali quando richiesto.

    In entrambi i casi, si consiglia di autorizzare la connessione OAuth durante la configurazione iniziale. Se si salta questo passo, non sarà possibile pubblicare le modifiche dal Designer e sarà necessario completare l'autorizzazione richiesta prima di tentare di distribuire le modifiche.

    Una volta autorizzato, viene visualizzato il messaggio Authorization has been provided.

    Nota
    
    OAuth è il tipo di autorizzazione consigliato. Utilizzare l'autenticazione Basic solo se si verificano problemi durante l'impostazione di una connessione OAuth. Per utilizzare l'autenticazione Basic, selezionare Usa Basic, quindi immettere le credenziali di un utente che può accedere all'istanza di Oracle Cloud Applications in Nome utente e Password. Queste credenziali devono essere quelle di un utente locale, non di un'identità federata e non devono richiedere l'autenticazione con più fattori.

    I token OAuth (accesso e aggiornamento) vengono attivati durante l'uso regolare. Un token di aggiornamento viene utilizzato per ottenere un token di accesso ogni volta che un utente accede all'istanza di destinazione. Questo token di aggiornamento è in genere valido per sette giorni. L'ora di scadenza del token è impostata nell'applicazione delle risorse IDCS e può essere diversa in base ai requisiti di sicurezza. Se l'utente esegue l'autenticazione con l'istanza di destinazione entro il periodo di sette giorni, il token di aggiornamento attivo genera un nuovo token di accesso e un nuovo token di aggiornamento. Questo ciclo continua a tempo indeterminato finché il token di aggiornamento rimane valido. Se il token di aggiornamento scade durante lunghi periodi di inattività (ad esempio, quando si è in vacanza), fare clic su Rinnova autorizzazione (oppure eseguire il job manualmente, quindi viene richiesto di autorizzare eventuali token OAuth scaduti).

    Il campo Crea artifact deve mostrare lo stesso nome di artifact utilizzato nel passo di creazione package. Confermare questo valore, soprattutto se il job di creazione package ha utilizzato un nome artifact diverso da quello predefinito, extension.vx.
17. Fare clic suSalva.

Per limitare l'accesso, il proprietario del progetto può contrassegnare un job come privato. Gli utenti che non dispongono dell'accesso possono visualizzare il job di build nella pagina Panoramica job, ma non possono visualizzare la pagina Dettagli job o i dettagli della build, né visualizzare o modificare la configurazione del job o eliminare/abilitare/disabilitare il job di build. Inoltre, il proprietario del progetto può utilizzare un pattern glob definito in una regola per proteggere qualsiasi job il cui nome corrisponde al pattern specificato.

1. Nel Navigator a sinistra, fare clic su Amministrazione progetto .
2. Selezionare la casella Build.
3. Selezionare la scheda Protezione job.

   Viene visualizzata la pagina Protezione job.

   
   
   Descrizione dell'immagine job-protection-page-initial.png
   

4. Nel pannello Trova regole per, situato sopra l'elenco di job/regole, selezionare uno dei seguenti pulsanti di opzione:
   • Selezionare Nome job per scegliere un job dalla lista.

     Se il tuo progetto ha molti lavori, potresti avere difficoltà a trovare il lavoro specifico che vuoi proteggere. Utilizzare la barra Filtra job per individuare rapidamente il job al quale si desidera aggiungere le impostazioni limitate.

     Se un job nell'elenco dei job a sinistra è associato all'icona a forma di lucchetto , è già stato protetto. Le restrizioni di un job protetto possono comunque essere modificate, rimosse o la lista di utenti e gruppi autorizzati può comunque essere modificata.

     Viene visualizzata la finestra di dialogo Protezione job.

     
     
     Descrizione dell'immagine job-protection: open.png
     

     Quando un job non è protetto direttamente ma è protetto da una regola, un messaggio informativo come il seguente mostrerà le regole, <ExampleRegex05> in questo caso, che proteggono il job specifico:

     This job is protected by the following glob pattern rules matching this job name: <ExampleRegex05>

   • Selezionare Pattern globale per specificare una stringa corrispondente al nome del job.

     Questo è ciò che vedresti se non sono state ancora definite regole.

     
     
     Descrizione dell'immagine job-protection-page-glob-pattern-selected.png
     

     La sintassi glob può essere utilizzata per specificare il comportamento di corrispondenza pattern. Questi caratteri jolly possono essere utilizzati nei pattern glob: *, **, ?, [], {} e \.

     Selezionare una regola di protezione esistente dalla lista oppure fare clic su + Regola per visualizzare la finestra di dialogo Nuova regola di protezione e crearne una nuova.

     Viene visualizzata la finestra di dialogo Regola di protezione.
     
     Descrizione dell'immagine protection-rule-dialog-populated.png
     In questo punto sono stati immessi un nome (regola di test) e un pattern glob (test*) e si sta per premere Crea per creare una nuova regola di protezione del job.

5. Selezionare la casella di controllo PRIVA.
   Questo è ciò che viene visualizzato dopo aver selezionato l'opzione Privato per un job.

   
   
   Descrizione dell'immagine job-protection: private.png
   

   Con questa opzione selezionata, solo gli utenti e i gruppi autorizzati saranno in grado di visualizzare la pagina Dettagli job, modificare o eseguire manualmente il job. Il job non verrà avviato se attivato in una pipeline da un utente o un gruppo non autorizzato o se attivato da SCM o da un timer.

   Questo è ciò che viene visualizzato dopo aver selezionato l'opzione Privato per una regola di protezione.

   
   
   Descrizione dell'immagine job-protection-rule-private.png
   

6. Fare clic nel campo Utenti/gruppi autorizzati per visualizzare una finestra di dialogo in cui sono elencati i gruppi e gli utenti del progetto tra cui è possibile effettuare la selezione.

   In Utenti è possibile visualizzare una lista appiattita di tutti gli utenti che sono membri del gruppo o dei gruppi e di quelli aggiunti singolarmente. Ad esempio, i membri del gruppo di sviluppo (Clara Coder, Don Developer e Tina Testsuite) vengono visualizzati nell'elenco Utenti, insieme ad Alex Admin, che è stato aggiunto singolarmente. Dalla lista, selezionare uno o più gruppi e/o utenti. Non dimenticare di aggiungere te stesso.

   
   
   Descrizione dell'immagine allowed-groups-and-users.png
   

   Questo è ciò che viene visualizzato per il job myProtectedJob dopo aver selezionato Alex Admin come utente autorizzato.

   
   
   Descrizione dell'immagine job-protection-private-authorized-user.png
   

   Questa è la regola di protezione Test Rule visualizzata dopo aver selezionato Alex Admin come utente autorizzato.

   
   
   Descrizione dell'immagine job-protection-rule-authorized-user.png
   

7. Selezionare le caselle di controllo per consentire ai membri del progetto di avviare manualmente job privati e/o consentire ai commit e ai trigger di avviare automaticamente job privati:

   • Selezionare la casella di controllo Consenti a qualsiasi membro del progetto di avviare manualmente questo job privato per consentire a qualsiasi membro del progetto, non solo agli utenti autorizzati, di avviare manualmente il job.

     Questo aspetto viene visualizzato dopo aver selezionato la casella di controllo Consenti a qualsiasi membro del progetto di avviare manualmente questo job privato per il job myProtectedJob.

     
     
     Descrizione dell'immagine job-protection-private-both-checkboxes-selected.png
     

     Si noti che quando si seleziona la prima casella di controllo, VB Studio seleziona automaticamente la seconda casella di controllo, che consente ai commit e ai trigger di avviare il job privato e di disattivarlo. Questa impostazione consente solo agli utenti e ai gruppi autorizzati di visualizzare la pagina Dettagli job o di modificare il job, ma qualsiasi membro del progetto può avviare ed eseguire il job. Inoltre, i trigger o i commit SCM avvieranno ed eseguiranno automaticamente il job.

     Questo aspetto viene visualizzato dopo aver selezionato la casella di controllo Consenti a qualsiasi membro del progetto di avviare manualmente questo job privato per la regola di protezione Regola di test.

     
     
     Descrizione dell'immagine job-protection-page-both-check-boxes.png
     

   • Selezionare solo la casella di controllo Consenti ai commit e ai trigger di avviare questo job privato se si desidera che i commit SCM e i trigger siano in grado di eseguire automaticamente questo job.

     
     
     Descrizione dell'immagine job-protection-private-allow-commits-and-triggers.png
     

     Con questa casella di controllo selezionata, i trigger periodici eseguiranno qualsiasi job o pipeline, inclusi i job privati impostati per consentire ai commit e ai trigger di avviare il job privato. Tuttavia, se una pipeline include un job privato con questa opzione selezionata e un utente non autorizzato tenta di eseguire manualmente la pipeline, il job privato non verrà eseguito, ma verranno eseguiti trigger periodici e commit SCM.

     Lasciare deselezionata la casella di controllo se non si desidera che il job venga avviato quando viene attivato da un commit o da un timer SCM.

     Nota
     
     

     Procedura ottimale:

     Se si utilizza la casella di controllo per abilitare l'attivazione della build protetta da un commit SCM, è necessario proteggere la diramazione a cui è collegato il job di build. In caso contrario, chiunque può attivare la build protetta eseguendo un commit per attivarla.

     Questo è ciò che viene visualizzato se per la regola di test è stato selezionato Consenti commit e trigger per avviare qualsiasi job corrispondente a questo pattern glob.

     
     
     Descrizione dell'immagine job-protection-page-allow-commits-and-triggers.png
     

8. Fare clic suSalva.

   Il flusso di attività visualizza tutte le modifiche allo stato di protezione di un job, ad esempio la modifica della protezione del job da pubblica a privata, da privata a pubblica o la modifica di un job privato per consentire commit e trigger.