Creare e configurare job di build di produzione

Di seguito sono riportate alcune informazioni che è necessario conoscere prima di configurare ed eseguire job e pipeline di build.

• 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 il job di packaging di sviluppo è stato configurato in modo da sovrascrivere la versione dell'applicazione definita in visual-application.json, ottenere la nuova versione. Verrà configurato il processo di creazione package di produzione in modo che utilizzi la stessa versione.
• VB Studio può creare e abilitare automaticamente i job di build e la pipeline. Nell'editor delle impostazioni dell'estensione, in Creazione e pubblicazione, selezionare la diramazione di produzione, quindi fare clic su Crea pipeline CI/CD. È quindi possibile modificare i job di build appena creati in base alle esigenze. Ad esempio, nel job di distribuzione, la destinazione di distribuzione è sempre l'ambiente associato all'area di lavoro, pertanto sarà necessario modificare l'istanza di destinazione nell'istanza di produzione.

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, in Nome, immettere un nome univoco.
4. In Descrizione, immettere la descrizione del job.
5. In Modello selezionare il modello Impostazione predefinita sistema OL7 per Visual Builder.
6. Fare clic su Crea.
7. Fare clic su Configura .
8. Fare clic sulla scheda Git.
9. Dall'elenco Aggiungi Git, selezionare Git.
10. In Repository selezionare il repository Git. In Diramazione o tag selezionare la diramazione di produzione.
11. Fare clic sulla scheda Passi.
12. In Aggiungi passo selezionare Estensione applicazione, quindi selezionare Pacchetto.
13. Per impostazione predefinita, la fase di packaging minimizza il codice sorgente dell'applicazione prima di eseguire la build. Se non si desidera minificare i file di origine, deselezionare la casella di controllo Ottimizza estensione.

    La minificazione è un processo per rimuovere i caratteri non necessari (ad esempio spazi vuoti, nuove righe e commenti) dal codice sorgente e ridurre le dimensioni dei file, rendendo il trasferimento di file consumare meno larghezza di banda e storage.

    Nota
    
    Quando si deseleziona la casella di controllo Ottimizza estensione, viene visualizzata questa avvertenza: Ottimizzazione non selezionata. Il packaging 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 Genera artifact. La procedura migliore consiste nel mantenere l'impostazione predefinita extension.vx, ma è possibile modificarla.
    Se 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 Creare il job di build di 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 creazione nella finestra Configurazione job.
17. In Aggiungi azione dopo la creazione selezionare Archiviatore artifact.
18. In File da archiviare, immettere il nome dell'artifact build.

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

    Se è stato immesso un valore nel campo Directory di destinazione in Copia artifact per il job di distribuzione, viene considerato come una sottodirectory dell'area di lavoro e deve far parte del percorso dell'artifact nel campo Crea 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 su Salva.

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, in Nome, immettere un nome univoco.
4. In Descrizione, immettere la descrizione del job.
5. In Modello selezionare il modello Impostazione predefinita sistema OL7 per Visual Builder.
6. Fare clic su Crea.
7. Fare clic su Configura .
8. Fare clic sulla scheda Prima della generazione.
9. In Aggiungi azione prima della build selezionare Copia artifact.
10. In Da job, selezionare il job di creazione package che ha generato l'artifact dell'estensione.
11. In Definizione selezionare una delle opzioni riportate di seguito.
    • Build riuscita più recente (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, è possibile che venga richiesto di selezionare il parametro permalink, build o build da utilizzare.
12. Lasciare gli altri campi con i valori predefiniti o vuoti.
13. Fare clic sulla scheda Passi.
14. In Aggiungi passo selezionare Estensione applicazione, quindi selezionare Distribuisci.

    Questa immagine mostra la pagina Distribuisci job build compilata parzialmente.
    
    Descrizione dell'illustrazione 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. Se 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 nell'istanza di Oracle Cloud Applications dell'ambiente. 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 ottenuta l'autorizzazione, 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 di base, selezionare Usa base, 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 ciclicati 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 risorsa IDCS e potrebbe 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 indefinitamente finché il token di aggiornamento rimane valido. Se il token di aggiornamento scade durante periodi prolungati di inattività (ad esempio, quando non si è in ferie), fare clic su Rinnova autorizzazione (o eseguire il job manualmente, in modo che venga richiesto di autorizzare eventuali token OAuth scaduti).

    Nel campo Crea artifact deve essere visualizzato lo stesso nome di artifact utilizzato nel passo di creazione package. Confermare questo valore, soprattutto se il job di creazione package utilizza un nome artifact diverso da quello predefinito, extension.vx.
17. Fare clic su Salva.

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 visualizzare i dettagli della build; né possono 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 navigatore 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'illustrazione job-protection-page-initial.png
   

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

     Se il tuo progetto ha molti lavori, potresti avere difficoltà a trovare il lavoro specifico che desideri proteggere. Utilizzare la barra Job di filtro per individuare rapidamente il job a cui si desidera aggiungere le impostazioni limitate.

     Fare clic con il pulsante destro del mouse sull'elenco dei job per visualizzare ulteriori opzioni di ordinamento. Fare clic su Ordina per nome job o su Ordina per job privato per ordinare la lista di conseguenza. Fare nuovamente clic sull'opzione di ordinamento per passare dall'ordine crescente a quello decrescente.

     
     
     

     Se un job ha un'icona a forma di lucchetto , è già stato protetto. È comunque possibile modificare, rimuovere o rimuovere le limitazioni di un job protetto oppure modificare l'elenco degli utenti e dei gruppi autorizzati.

     Viene visualizzata la finestra di dialogo Protezione job.

     
     
     Descrizione dell'illustrazione job-protection-open.png
     

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

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

   • Selezionare Modello a livello di globo per specificare una stringa corrispondente al nome del job.

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

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

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

     Selezionare una regola di protezione esistente dall'elenco 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'illustrazione protection-rule-dialog-populated.png
     Qui 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 job.

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

   
   
   Descrizione dell'illustrazione job-protection-private.png
   

   Solo l'opzione selezionata consente di visualizzare la pagina Dettagli job, modificare il job o eseguirlo manualmente solo agli utenti e ai gruppi autorizzati. Il job viene avviato se attivato in una pipeline da un utente o da un gruppo non autorizzato oppure 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'illustrazione 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 un elenco appiattito di tutti gli utenti che sono membri del gruppo o dei gruppi e di quelli che sono stati 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. Selezionare uno o più gruppi e/o utenti dall'elenco. Non dimenticare di aggiungere te stesso.

   
   
   Descrizione dell'illustrazione autorizzato-groups-users.png
   

   Questo è ciò che vedresti per il lavoro myProtectedJob dopo aver selezionato Alex Admin come utente autorizzato.

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

   Questo è ciò che vedresti per la regola di protezione della regola di test dopo aver selezionato Alex Admin come utente autorizzato.

   
   
   Descrizione dell'illustrazione 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 questo job.

     Ciò che 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'illustrazione 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 lo disattiva. Con questa impostazione, solo gli utenti e i gruppi autorizzati possono visualizzare la pagina Dettagli job o modificare il job, ma qualsiasi membro del progetto può avviare ed eseguire il job. Inoltre, i commit o i trigger SCM avvieranno ed eseguiranno automaticamente il job.

     Ciò che 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'illustrazione job-protection-page-both-check-boxes.png
     

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

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

     Selezionando questa casella di controllo, 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 i trigger periodici e i commit SCM verranno eseguiti.

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

     Nota
     
     

     Procedura ottimale:

     Se si utilizza la casella di controllo per abilitare l'attivazione della build protetta da parte di un commit SCM, è necessario proteggere la diramazione a cui è collegato il job di build. Se non lo fai, chiunque può attivare la build protetta effettuando un commit per attivarla.

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

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

8. Fare clic su Salva.

   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 o da privata a pubblica oppure la modifica di un job privato per consentire commit e trigger.