Personalizzazione toolchain

Personalizzare la toolchain aggiungendo la toolchain a più app e aumentandone la funzionalità. La procedura è la seguente:

1. Aggiungi un'integrazione dello strumento GitHub per ciascuna applicazione che vuoi creare nelle pipeline della toolchain.
2. Aggiungi ulteriori integrazioni GitHub per qualsiasi altro problema, inventario e repository di prove che possono essere configurati per determinate applicazioni.

• Fare riferimento alle pagine della documentazione e alle procedure ottimali per comprendere se sono necessari questi repository aggiuntivi per le applicazioni.

• Un sottosistema è un gruppo di servizi correlati che dipendono l'uno dall'altro e vengono sviluppati e implementati insieme.

  • I servizi all'interno di un singolo sottosistema devono condividere un archivio comune delle scorte e un deposito delle prove. Ogni sottosistema deve mantenere un rapporto 1:1 tra il proprio archivio dell'inventario e l'archivio delle prove. La ricerca di prove su più armadietti non è supportata, poiché amplia lo spazio di ricerca e aumenta il rischio di conflitti tra i dati.
  • È anche possibile raggruppare più sottosistemi per utilizzare lo stesso inventario e armadietto condivisi.
  • Esempio: raggruppare servizi correlati (come auth e user-profile) in un unico sottosistema. Questo modello supporta la gestione scalabile dei microservizi in Continuous Delivery ambienti.

• I repository Application possono anche fungere da proprio repository di problemi. Questo è applicabile solo quando l'opzione dei problemi GitHub è abilitata sull'integrazione dello strumento.

• Il repository Inventory deve essere sufficiente come un singolo repository consolidato per registrare i tuoi record di build perché i record sono già divisi per app-name, purché tale parametro sia diverso, nulla andrà perso o confuso. Anche se potresti voler consultare la documentazione dell'inventario per idee su come gestire questo repository perché la sua funzione principale è aiutare a supportare le distribuzioni nella pipeline di distribuzione continua.

1. Configura un bucket IBM Cloud® Object Storage.

   IBM Cloud Object Storage è il metodo locker delle prove preferito per le risorse delle prove della pipeline ed è richiesto per la conformità del controllo. Utilizza lo stesso bucket Object Storage per ogni applicazione che porti nella toolchain CI. Riutilizza inoltre lo stesso bucket Object Storage quando stai integrando la tua toolchain CI con la toolchain CD o CC.

2. Facoltativo: integrazioni HashiCorp Vault aggiuntive.

   Poiché l'integrazione dello strumento HashiCorp Vault supporta solo un percorso, potresti aver bisogno di più di essi a seconda di come sono configurati i tuoi segreti HashiCorp Vault. Applicazioni differenti potrebbero richiedere credenziali diverse o altre tra loro.

Personalizzazione della pipeline di IC e PR

Personalizzare l'IC e la pipeline di PR configurandoli utilizzando la procedura riportata di seguito:

1. Crea un trigger Git per ogni applicazione.

   • Copiare i trigger esistenti per salvare alcuni tedium quando si creano i trigger.
   • Assicurati che ciascuno dei trigger punti al repository e al ramo GitHub richiesti.
   • Assicurarsi che le seguenti proprietà del trigger siano impostate:
     • app-name (testo): i nomi delle app devono essere univoci tra le diverse applicazioni. Ciò è dovuto al fatto che il nome dell'applicazione viene utilizzato nell'inventario, negli insight DevOps e in altri come identificativo univoco quando viene inserito e registrato con le risorse utente.
     • cos-bucket-name (testo): Il nome del Object Storage bucket in cui sono collocate le prove delle applicazioni.

2. Le modifiche delle proprietà dell'ambiente per ogni applicazione.

   • Questo è un elenco delle possibili proprietà di ambiente che devono essere modificate in un valore diverso per ciascuna delle applicazioni. Ciò può essere realizzato utilizzando le proprietà del trigger sui trigger della pipeline, che sovrascrive le proprietà ambientali con i propri valori scelti.
     • app-name (testo): i nomi applicazione devono essere sempre univoci tra le diverse applicazioni perché il nome applicazione viene utilizzato nell'inventario, negli insight DevOps e così via, come un identificativo univoco quando si posizionano e registrano le risorse utente.
     • cos-bucket-name (testo): Il nome del Object Storage bucket in cui sono collocate le prove delle applicazioni.
     • repository (text): questo parametro controlla quale repository dell'applicazione viene clonato nella pipeline e serve come destinazione per le pipeline CI e PR per le varie attività di conformità e sicurezza.
     • Opzionale: evidence-repo (testo): URL del repo che funge da deposito di prove per l'applicazione.
     • Opzionale: incident-repo (testo): URL del repo che funge da repo dei problemi per l'applicazione.
     • Opzionale: inventory-repo (testo): URL del repository che funge da repository di inventario per l'applicazione.

3. optional step Impostare i trigger manuali per ogni applicazione.

   • Tecnicamente è necessario un solo trigger manuale perché le relative proprietà possono essere modificate al momento della chiamata, ma potrebbe essere utile per i team disporre di trigger manuali precomposti per salvare alcuni passi nella scrittura di tutte le possibili piccole differenze tra le app.

4. optional step Crea trigger Timer per le applicazioni.

   • Si consiglia di ricreare e riconvalidare frequentemente un'applicazione, in modo da poter tenere conto di eventuali problemi di conformità e vulnerabilità, nonché di eventuali problemi di build.
   • Configurare le proprietà del trigger nello stesso modo in cui è stato configurato il trigger manuale perché il trigger del timer è solo un trigger manuale su un timer.
   • Esegui lo scaglionamento dei tuoi lavori cron l'uno dall'altro, altrimenti potresti sovraccaricare il cluster di nodi di lavoro e i tuoi lavori potrebbero subire un aumento dei tempi di creazione o un ritardo tra le fasi.

Per informazioni sulle altre proprietà che possono essere impostate sui trigger della pipeline o all'interno delle proprietà dell'ambiente, vedi il catalogo dei parametri della pipeline.