Questo documento descrive l'architettura complessiva di un sistema di machine learning (ML) utilizzando TensorFlow Extended (TFX) librerie. Inoltre, illustra come configurare un'integrazione continua (CI), distribuzione continua (CD) e addestramento continuo (CT) per il sistema ML utilizzando Cloud Build e Vertex AI Pipelines,
In questo documento, i termini sistema ML e pipeline ML fanno riferimento al modello ML. pipeline di addestramento, anziché pipeline di punteggio o previsione del modello.
Questo documento è rivolto a data scientist e ML engineer che vogliono adattare il proprio pratiche CI/CD per spostare le soluzioni ML in produzione su Google Cloud e chi vuole per contribuire a garantire qualità, manutenibilità e l'adattabilità delle pipeline ML.
Questo documento tratta i seguenti argomenti:
- Comprendere CI/CD e automazione nel ML.
- Progettazione di una pipeline ML integrata con TFX.
- Orchestrare e automatizzare la pipeline ML utilizzando Vertex AI Pipelines.
- Configurazione di un sistema CI/CD per la pipeline ML utilizzando Cloud Build.
MLOps
Per integrare un sistema ML in un ambiente di produzione, è necessario orchestrare i passaggi nella tua pipeline ML. Inoltre, devi automatizzare l'esecuzione della pipeline per l'addestramento continuo dei tuoi modelli. Per sperimentare con nuove idee e funzionalità, devi adottare le pratiche di CI/CD nella nuova le implementazioni delle pipeline. Le seguenti sezioni forniscono una panoramica Panoramica di CI/CD e CT in ML.
Automazione di pipeline ML
In alcuni casi d'uso, il processo manuale di addestramento, convalida e deployment modelli possono essere sufficienti. Questo approccio manuale funziona se il tuo team gestisce solo alcuni modelli ML che non vengono riaddestrati o che non vengono modificati di frequente. In pratica, Tuttavia, spesso i modelli si guastano quando vengono implementati nel mondo reale perché non si adattano ai cambiamenti nelle dinamiche degli ambienti o ai dati che descrive tali dinamiche.
Affinché il tuo sistema ML si adatti a queste modifiche, devi applicare quanto segue Tecniche MLOps:
- Automatizza l'esecuzione della pipeline di ML per riaddestrare nuovi modelli su nuovi per acquisire eventuali pattern emergenti. Più avanti in questo articolo parleremo di CT. documento nel ML con Vertex AI Pipelines .
- Configura un sistema di distribuzione continua per eseguire frequentemente il deployment di nuovi implementazioni dell'intera pipeline ML. CI/CD verrà discusso più avanti in questo documento nel Configurazione CI/CD per ML su Google Cloud .
Puoi automatizzare le pipeline di produzione ML per riaddestrare i modelli con nuovi dati. Puoi attivare la tua pipeline on demand, in base a una pianificazione, in base alla disponibilità nuovi dati, sul peggioramento delle prestazioni del modello, su modifiche significative le proprietà statistiche dei dati o in base ad altre condizioni.
Pipeline CI/CD a confronto con pipeline CT
La disponibilità di nuovi dati è un trigger per riaddestrare il modello ML. La disponibilità di una nuova implementazione della pipeline ML (inclusi i nuovi architettura, feature engineering e iperparametri) è un'altra importante un trigger per eseguire nuovamente la pipeline ML. Questa nuova implementazione della pipeline ML funge da nuova versione del servizio di previsione del modello, ad esempio una con un'API REST per la distribuzione online. La differenza tra i due sono i seguenti:
- Per addestrare un nuovo modello ML con nuovi dati, la pipeline CT di cui è stato eseguito il deployment in precedenza viene eseguito. Non viene eseguito il deployment di nuove pipeline o nuovi componenti. solo un nuovo un servizio di previsione o un modello appena addestrato viene fornito alla fine della pipeline.
- Per addestrare un nuovo modello ML con una nuova implementazione, occorre creare una nuova pipeline il deployment tramite una pipeline CI/CD.
Per eseguire rapidamente il deployment di nuove pipeline ML, devi configurare una pipeline CI/CD. Questa pipeline è responsabile del deployment automatico di nuove pipeline ML quando sono disponibili e approvate nuove implementazioni per vari di sviluppo, test, gestione temporanea, pre-produzione, e produzione).
Il seguente diagramma mostra la relazione tra la pipeline CI/CD e la pipeline ML CT.
Figura 1. pipeline CI/CD e ML CT.
L'output per queste pipeline è il seguente:
- Se viene adottata una nuova implementazione, una pipeline CI/CD di successo esegue il deployment di una nuova pipeline ML CT.
- Se vengono forniti nuovi dati, una pipeline CT di successo addestra un nuovo modello e ne esegue il deployment come servizio di previsione.
Progettazione di un sistema ML basato su TFX
Le sezioni seguenti illustrano come progettare un sistema ML integrato utilizzando TensorFlow Extended (TFX) per configurare una pipeline CI/CD per il sistema ML. Sebbene esistano diversi framework per la creazione di modelli ML, TFX è un una piattaforma ML integrata per lo sviluppo e il deployment di sistemi ML di produzione. Una pipeline TFX è una sequenza di componenti che implementano un sistema ML. Questa pipeline TFX è progettata per attività di ML scalabili e ad alte prestazioni. Queste attività includono modellazione, addestramento, convalida, inferenza e alla gestione dei deployment. Le librerie delle chiavi di TFX sono le seguenti:
- TensorFlow Data Validation (TFDV): Utilizzato per rilevare le anomalie nei dati.
- TensorFlow Transform (TFT): Utilizzato per la pre-elaborazione dei dati e il feature engineering.
- Strumento per la stima di TensorFlow e Keras: Utilizzato per creare e addestrare modelli ML.
- TensorFlow Model Analysis (TFMA): Utilizzato per la valutazione e l'analisi del modello ML.
- Pubblicazione di TensorFlow (TFServing): Utilizzato per gestire modelli ML come API REST e gRPC.
Panoramica del sistema TFX ML
Il seguente diagramma mostra come sono integrate le varie librerie TFX per comporre un sistema di ML.
Figura 2. Un tipico sistema ML basato su TFX.
La figura 2 mostra un tipico sistema ML basato su TFX. È possibile eseguire i seguenti passaggi manualmente o mediante una pipeline automatizzata:
- Estrazione dati: il primo passaggio consiste nell'estrarre i nuovi dati di addestramento le sue origini dati. Gli output di questo passaggio sono file di dati usati per addestrare e valutare il modello.
- Convalida dei dati: TFDV convalida i dati rispetto ai dati previsti (non elaborati) . Lo schema dei dati viene creato e corretto durante la fase di sviluppo, prima del deployment del sistema. I passaggi di convalida dei dati rilevano anomalie relative sia alla distribuzione dei dati sia ai disallineamenti dello schema. Gli output di questo passaggio le anomalie (se presenti) e la decisione di eseguire il downstream passi o meno.
- Trasformazione dei dati: dopo la convalida dei dati, questi vengono suddivisi e
preparati per l'attività di ML mediante l'esecuzione di trasformazioni e caratteristiche
di machine learning utilizzando TFT. Gli output di questo passaggio sono file di dati
ad addestrare e valutare il modello, di solito
TFRecords
formato. Inoltre, gli artefatti di trasformazione prodotti aiutano a costruire gli input del modello e incorporano il processo di trasformazione nel modello salvato esportato dopo l'addestramento. - Addestramento e ottimizzazione del modello: per implementare e addestrare il modello ML, utilizza
tf.Keras
con i dati trasformati prodotti dal passaggio precedente. A selezionare le impostazioni dei parametri che portano al modello migliore, puoi utilizzare Sintonizzatore Keras, una libreria di ottimizzazione degli iperparametri per Keras. In alternativa, puoi utilizzare altri servizi come Katib, Vertex AI Vizier, o l'ottimizzazione degli iperparametri Vertex AI. L'output di questo passaggio è un modello salvato che viene utilizzato per la valutazione un altro modello salvato che viene usato per la distribuzione online del modello a scopo di previsione. - Valutazione e convalida del modello: quando il modello viene esportato dopo il passaggio di addestramento, viene valutato su un set di dati di test per valutare la qualità del modello mediante TFMA. TFMA valuta la qualità del modello nel suo complesso e identifica quale parte del modello dei dati non è efficace. Questa valutazione aiuta garantire che il modello venga promosso per la pubblicazione solo se soddisfa le criteri di qualità. I criteri possono includere equità di prestazioni su vari dati sottoinsiemi (ad es. dati demografici e località) e miglioramento del rendimento rispetto ai modelli precedenti o a un modello di benchmark. L'output di questo passaggio è un insieme di metriche delle prestazioni e la decisione di promuovere il modello alla produzione.
- Distribuzione del modello per la previsione: una volta convalidato il modello appena addestrato, il deployment viene eseguito come microservizio per fornire le previsioni online utilizzando TensorFlow Pubblicazione. L'output di questo passaggio è un servizio di previsione del deployment addestrato nel modello ML. Puoi sostituire questo passaggio archiviando il modello addestrato in in un registro dei modelli. Successivamente, viene creato un modello separato per il processo CI/CD è stato avviato.
Per un esempio su come utilizzare le librerie TFX, guarda il tutorial ufficiale sul componente TFX Keras.
Sistema TFX ML su Google Cloud
In un ambiente di produzione, i componenti del sistema devono essere eseguiti su larga scala su una piattaforma affidabile. Il seguente diagramma mostra come ogni passaggio del flusso di lavoro ML viene eseguita utilizzando un servizio gestito su Google Cloud, che garantisce l'agilità, affidabilità e prestazioni su larga scala.
Figura 3. Sistema ML basato su TFX su Google Cloud.
La tabella seguente descrive la chiave Servizi Google Cloud mostrati nella figura 3:
Passaggio | Libreria TFX | Servizio Google Cloud |
---|---|---|
Estrazione e convalida dei dati | Convalida dei dati TensorFlow | Dataflow |
Trasformazione dei dati | TensorFlow Transform | Dataflow |
Addestramento e ottimizzazione del modello | TensorFlow | Vertex AI Training |
Valutazione e convalida del modello | Analisi del modello TensorFlow | Dataflow |
Distribuzione del modello per le previsioni | Distribuzione di TensorFlow | Previsione Vertex AI |
Archiviazione modello | N/D | Registro dei modelli di Vertex AI |
- Dataflow
è un servizio completamente gestito, serverless e affidabile per l'esecuzione,
Apache Beam
su vasta scala in Google Cloud. Dataflow
viene utilizzato per scalare i seguenti processi:
- Calcolo delle statistiche per convalidare i dati in arrivo.
- Esecuzione della preparazione e della trasformazione dei dati.
- Valutazione del modello su un set di dati di grandi dimensioni.
- Metriche di calcolo su diversi aspetti del set di dati di valutazione.
- Cloud Storage
è uno spazio di archiviazione ad alta disponibilità e durevole per oggetti binari di grandi dimensioni.
Cloud Storage ospita gli artefatti prodotti
durante l'esecuzione della pipeline ML, inclusi quanto segue:
- Anomalie dei dati (se presenti)
- Dati e artefatti trasformati
- Modello esportato (addestrato)
- Metriche di valutazione del modello
- Addestramento Vertex AI è un servizio gestito per addestrare modelli ML su larga scala. Puoi eseguire il modello di job di addestramento container predefiniti per TensorFlow, Scikit-learn, XGBoost e PyTorch. Puoi anche eseguire qualsiasi il tuo framework utilizzando il tuo container personalizzati. Per infrastruttura di addestramento puoi usare acceleratori e nodi multipli per l'addestramento distribuito. Inoltre, è disponibile un servizio scalabile basato sull'ottimizzazione bayesiana per ottimizzazione degli iperparametri è disponibile
- Previsione Vertex AI è un servizio gestito per eseguire Previsioni batch utilizzando i modelli addestrati previsioni online eseguendo il deployment dei tuoi modelli come microservizi con un'API REST. Il servizio si integra anche con Vertex Explainable AI e Vertex AI Model Monitoring per comprendere i tuoi modelli e ricevere avvisi quando c'è una funzionalità il disallineamento e la deviazione dell'attribuzione delle caratteristiche.
- Vertex AI Model Registry consente di gestire il ciclo di vita dei modelli ML. Puoi controllare la versione importati e visualizzarne le metriche sulle prestazioni. Un modello può quindi essere utilizzato per le previsioni batch o esegui il deployment del modello per la distribuzione online Vertex AI Prediction
Orchestrare il sistema ML utilizzando Vertex AI Pipelines
Questo documento spiega come progettare un sistema ML basato su TFX e come eseguire ogni componente del sistema su larga scala su Google Cloud. Tuttavia, è necessaria orchestrator per collegare questi diversi componenti del sistema in sinergia. Lo strumento di orchestrazione esegue la pipeline in sequenza e si sposta da un passaggio all'altro in base alle condizioni definite. Ad esempio, un la condizione definita potrebbe eseguire il passaggio di pubblicazione del modello dopo passaggio di valutazione se le metriche di valutazione soddisfano soglie predefinite. I passaggi possono anche in parallelo per risparmiare tempo, ad esempio convalidare il deployment dell'infrastruttura e valutare il modello. L'orchestrazione della pipeline ML è utile sia nella fase di sviluppo che in quella di produzione:
- Durante la fase di sviluppo, l'orchestrazione aiuta i data scientist a anziché eseguire manualmente ogni passaggio.
- Durante la fase di produzione, l'orchestrazione consente di automatizzare l'esecuzione la pipeline ML in base a una pianificazione o a determinate condizioni di attivazione.
ML con Vertex AI Pipelines
Vertex AI Pipelines è un servizio gestito di Google Cloud che ti consente di orchestrare e automatizzare Pipeline ML in cui ogni componente della pipeline può essere eseguito Google Cloud o altre piattaforme cloud. Parametri e artefatti della pipeline vengono archiviati automaticamente Metadati Vertex ML il che consente il monitoraggio della derivazione e dell'esecuzione. Il servizio Vertex AI Pipelines è costituito da:
- Interfaccia utente per la gestione e il monitoraggio di esperimenti, job ed esecuzioni.
- Un motore per la pianificazione di flussi di lavoro ML in più fasi.
- R SDK Python per definire e manipolare pipeline e componenti.
- Integrazione con Vertex ML Metadata per salvare informazioni su esecuzioni, modelli, set di dati e altri artefatti.
Quanto segue costituisce una pipeline eseguita su Vertex AI Pipelines:
- Un insieme di attività o componenti ML containerizzati. Un componente della pipeline è un codice autonomo pacchettizzato come Immagine Docker. Un componente esegue un passaggio nella pipeline. Prende argomenti di input e produce artefatti.
- Una specifica della sequenza di attività ML, definita mediante un lingua specifica del dominio (DSL). La topologia del flusso di lavoro viene definita implicitamente collegando gli output di un passaggio a monte agli input di un passaggio a valle. Un passaggio nella pipeline di definizione richiama un componente nella pipeline. In una pipeline complessa, i componenti possono essere eseguiti più volte in loop oppure possono essere eseguiti in modo condizionale.
- Un insieme di parametri di input della pipeline, i cui valori vengono passati al componenti della pipeline, tra cui i criteri per filtrare i dati e dove archiviare gli artefatti prodotti dalla pipeline.
Il seguente diagramma mostra un grafico di esempio di Vertex AI Pipelines.
Figura 4. Un grafico di esempio di Vertex AI Pipelines.
SDK Kubeflow Pipelines
La SDK Kubeflow Pipelines consente di creare componenti, definirne l'orchestrazione ed eseguirli come pipeline. Per maggiori dettagli sui componenti di Kubeflow Pipelines, consulta Creare componenti nella documentazione di Kubeflow.
Puoi utilizzare anche DSL pipeline TFX e utilizza Componenti TFX. Un componente TFX incapsula le funzionalità dei metadati. Il conducente fornisce i metadati all'esecutore eseguendo una query sull'archivio metadati. Il publisher accetta i risultati dell'esecutore e li archivia nei metadati. Puoi anche implementare tuo componente personalizzato, che ha la stessa integrazione con i metadati. Puoi compilare i campi TFX a un codice YAML compatibile con Vertex AI Pipelines utilizzando tfx.orchestration.experimental.KubeflowV2DagRunner. Quindi, puoi inviare il file a Vertex AI Pipelines per l'esecuzione.
Il seguente diagramma mostra come in Vertex AI Pipelines, un container un'attività può richiamare altri servizi, come job BigQuery, Job di addestramento Vertex AI (distribuito) e Dataflow di lavoro.
Figura 5. Richiamo di Vertex AI Pipelines servizi gestiti di Google Cloud.
Vertex AI Pipelines ti consente di orchestrare e automatizzare una produzione mediante l'esecuzione dei servizi Google Cloud richiesti. Nella figura 5, Vertex ML Metadata funge da metadato ML. per Vertex AI Pipelines.
I componenti della pipeline non si limitano all'esecuzione di servizi correlati a TFX su in Google Cloud. Questi componenti possono eseguire qualsiasi servizi, tra cui Dataproc per i job SparkML, AutoML e altri carichi di lavoro di computing.
La containerizzazione delle attività in Vertex AI Pipelines offre i seguenti vantaggi:
- Disaccoppia l'ambiente di esecuzione dal runtime del codice.
- Fornisce la riproducibilità del codice nell'ambiente di sviluppo e di produzione, perché gli elementi che test sono gli stessi in produzione.
- Isola ogni componente della pipeline; ciascuno può avere la propria versione del runtime, linguaggi e librerie diverse.
- Aiuta con la composizione di pipeline complesse.
- Si integra con Vertex ML Metadata per la tracciabilità e la riproducibilità di esecuzioni e artefatti della pipeline.
Per un'introduzione completa a Vertex AI Pipelines, consulta l'elenco delle esempi di blocchi note.
Attivazione e pianificazione di Vertex AI Pipelines
Quando esegui il deployment di una pipeline in produzione, devi automatizzarne le esecuzioni, a seconda degli scenari descritti Automazione delle pipeline di ML .
La SDK Vertex AI consente di gestire la pipeline in modo programmatico. La classe google.cloud.aiplatform.PipelineJob che include API per la creazione di esperimenti, il deployment e l'esecuzione di pipeline. Utilizzando l'SDK, puoi quindi richiamare Vertex AI Pipelines da con un altro servizio per ottenere trigger basati su eventi o scheduler.
Figura 6. Diagramma di flusso che mostra più trigger per Vertex AI Pipelines utilizzando Pub/Sub e Cloud Functions.
Nella figura 6 è riportato un esempio su come attivare la funzione Servizio Vertex AI Pipelines per eseguire una pipeline. La pipeline viene attivata utilizzando l'SDK Vertex AI da una la funzione Cloud Function. La funzione Cloud Functions stessa è un sottoscrittore in Pub/Sub e si attiva in base ai nuovi messaggi. Qualsiasi servizio che voglia per attivare l'esecuzione della pipeline, puoi pubblicare sul Pub/Sub. L'esempio precedente include tre servizi di pubblicazione:
- Cloud Scheduler pubblica i messaggi in base a una pianificazione e quindi attiva la pipeline.
- Cloud Composer sta pubblicando messaggi nell'ambito di un flusso di lavoro più ampio, come flusso di lavoro di importazione che attiva la pipeline di addestramento dopo BigQuery importa nuovi dati.
- Cloud Logging pubblica un messaggio basato su log che soddisfano alcuni criteri di filtro. Potete impostare i filtri per rilevare l'arrivo di nuovi dati o anche gli avvisi di disallineamento e deviazione generati Vertex AI Model Monitoring completamente gestito di Google Cloud.
Configurazione di CI/CD per ML su Google Cloud
Vertex AI Pipelines ti consente di orchestrare sistemi ML che comporta più passaggi, tra cui la pre-elaborazione dei dati, l'addestramento del modello la valutazione e il deployment del modello. Nella fase di esplorazione della data science, Vertex AI Pipelines consente di sperimentare rapidamente l'intero di un sistema operativo completo. Nella fase di produzione, Vertex AI Pipelines consente di automatizzare l'esecuzione della pipeline in base a nuovi dati per addestrare modello ML personalizzato.
Architettura CI/CD
Il seguente diagramma mostra una panoramica generale di CI/CD per il machine learning con Vertex AI Pipelines.
Figura 7: panoramica generale di CI/CD con Vertex AI Pipelines.
Il nucleo di questa architettura è Cloud Build. Cloud Build può importare l'origine da Cloud Source Repositories. GitHub o Bitbucket, ed eseguire una build secondo le tue specifiche e produrre artefatti come container Docker o file tar Python.
Cloud Build esegue la build come una serie di passaggi di build
definiti in un
file di configurazione della build
(cloudbuild.yaml
). Ogni passaggio di build viene eseguito in un container Docker. Puoi
o
utilizza i passaggi di build supportati
forniti da Cloud Build
scrivi i tuoi passaggi di build.
Il processo Cloud Build, che esegue le operazioni CI/CD richieste per di ML, possono essere eseguite manualmente o tramite Trigger di build automatizzati. I trigger eseguono i passaggi di build configurati ogni volta che viene eseguito il push delle modifiche all'origine della build. Puoi impostare un trigger di build su cui eseguire la routine di build modifiche al repository di codice sorgente o eseguire la routine di build solo quando le modifiche soddisfano determinati criteri.
Inoltre, puoi creare routine (Cloud Build di configurazione) che vengono eseguiti in risposta a diversi trigger. Per Ad esempio, puoi avere routine di creazione che vengono attivate quando vengono eseguiti i commit al ramo di sviluppo o al ramo principale.
Puoi usare la variabile di configurazione
sostituzioni
per definire le variabili di ambiente
al momento della creazione. Queste sostituzioni sono
acquisite dalle build attivate. Queste variabili includono $COMMIT_SHA
,
$REPO_NAME
, $BRANCH_NAME
, $TAG_NAME
e $REVISION_ID
. Altro
le variabili non basate su attivatori sono $PROJECT_ID
e $BUILD_ID
. Le sostituzioni sono
utile per le variabili il cui valore non è noto fino al momento della creazione, oppure per riutilizzare un
richiesta di build esistente con diversi valori della variabile.
Caso d'uso del flusso di lavoro CI/CD
In genere un repository di codice sorgente include i seguenti elementi:
- Codice sorgente del flusso di lavoro delle pipeline Python in cui è definito il flusso di lavoro della pipeline
- Il codice sorgente dei componenti della pipeline Python e il componente corrispondente i file delle specifiche per i diversi componenti della pipeline, come i dati la convalida, la trasformazione dei dati, l'addestramento del modello, la valutazione la pubblicazione del modello.
- i Dockerfile necessari per creare immagini container Docker, una per ogni componente della pipeline.
- L'unità Python e i test di integrazione per testare i metodi implementati nel e la pipeline complessiva.
- Altri script, tra cui il file
cloudbuild.yaml
, trigger di test e deployment della pipeline. - I file di configurazione (ad esempio il file
settings.yaml
), tra cui ai parametri di input della pipeline. - Notebooks vengono utilizzati per l'analisi esplorativa dei dati, l'analisi del modello e sperimentazione interattiva sui modelli.
Nell'esempio seguente, una routine di build viene attivata quando uno sviluppatore esegue il push il codice sorgente al ramo dello sviluppo dall'ambiente di data science.
Figura 8. Esempi di passi di build eseguiti da Cloud Build.
Cloud Build esegue in genere la build seguente passaggi, che sono mostrati anche nella Figura 7:
- Il repository di codice sorgente viene copiato in Cloud Build
dell'ambiente di runtime, nella directory
/workspace
. - Esegui test delle unità e di integrazione.
- (Facoltativo) Esegui l'analisi statica del codice utilizzando un analizzatore come Pylint.
- Se i test vengono superati, vengono create le immagini container Docker, una per
della pipeline. Alle immagini è associato il tag
Parametro
$COMMIT_SHA
. - Le immagini container Docker vengono caricate in Artifact Registry (come illustrato figura 7).
- L'URL dell'immagine viene aggiornato in ciascuno dei file
component.yaml
con il immagini container Docker create e taggate. - Il flusso di lavoro della pipeline viene compilato
pipeline.json
. - Il file
pipeline.json
è stato caricato in Artifact Registry. - (Facoltativo) Esegui la pipeline con i valori parametro come parte di una il test di integrazione o l'esecuzione in produzione. La pipeline eseguita genera un nuovo modello e potrebbe anche eseguirne il deployment come API Vertex AI Prediction.
Per un esempio MLOps end-to-end pronto per la produzione che include CI/CD utilizzando Cloud Build, consulta gli esempi end-to-end di Vertex Pipelines su GitHub.
Ulteriori considerazioni
Quando configuri l'architettura CI/CD ML su Google Cloud, tieni in considerazione quanto segue:
- Per l'ambiente di data science, puoi utilizzare una macchina locale oppure Vertex AI Workbench
- Puoi configurare la pipeline automatizzata di Cloud Build ignora trigger, ad esempio, se vengono modificati solo i file di documentazione o se i blocchi note degli esperimenti vengono modificati.
- Puoi eseguire la pipeline per i test di integrazione e regressione come
il test di build. Prima del deployment della pipeline nella destinazione
puoi utilizzare
wait()
per attendere il completamento dell'esecuzione della pipeline inviata. - Come alternativa a Cloud Build, puoi usare altre build sistemi come Jenkins. È disponibile un deployment di Jenkins pronto all'uso Google Cloud Marketplace.
- Puoi configurare la pipeline per il deployment automatico diversi ambienti, tra cui sviluppo, test e gestione temporanea, in base diversi trigger. Inoltre, puoi eseguire il deployment manualmente, come la pre-produzione o la produzione, in genere dopo per ottenere l'approvazione di una release. Puoi avere più routine di creazione diversi trigger o per diversi ambienti di destinazione.
- Puoi utilizzare Apache Airflow, un popolare framework di orchestrazione e pianificazione, per uso generico che puoi eseguire utilizzando il framework Cloud Composer completamente gestito di Google Cloud. Per ulteriori informazioni su come orchestrare le pipeline di dati con Cloud Composer e Cloud Build, per Impostazione di una pipeline CI/CD per il flusso di lavoro di elaborazione dati.
- Quando esegui il deployment di una nuova versione del modello in produzione, esegui il deployment canary per avere un'idea delle sue prestazioni (CPU, memoria utilizzo del disco). Prima di configurare il nuovo modello per gestire tutto il traffico in tempo reale, puoi anche eseguire test A/B. Configura il nuovo modello per la pubblicazione del 10% su il 20% del traffico in tempo reale. Se il nuovo modello ha prestazioni migliori di quello attuale, puoi configurare il nuovo modello per gestire tutto il traffico. In caso contrario, il sistema di pubblicazione esegue il rollback al modello corrente.
Passaggi successivi
- Scopri di più su Distribuzione continua in stile GitHub con Cloud Build.
- Scopri di più su Impostazione di una pipeline CI/CD per il flusso di lavoro di elaborazione dati.
- Per altre architetture di riferimento, diagrammi e best practice, esplora il Centro architetture cloud.
Collaboratori
Autori:
- Ross Thomson | Cloud Solutions Architect
- Salama calidica | Ingegnere informatico del personale, machine learning
Altro collaboratore: Wyatt Gorman | Responsabile soluzioni HPC