Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
L'integrazione continua e il recapito continuo (CI/CD) si riferisce al processo di sviluppo e distribuzione di software in brevi cicli frequenti tramite l'uso di pipeline di automazione. CI/CD è comune nello sviluppo di software e sta diventando sempre più necessario nella progettazione dei dati e nell'analisi scientifica dei dati. Automatizzando la compilazione, il test e la distribuzione del codice, i team di sviluppo offrono versioni più affidabili rispetto ai processi manuali.
Databricks fornisce strumenti per lo sviluppo di pipeline CI/CD che supportano approcci che possono differire leggermente dall'organizzazione all'organizzazione a causa di aspetti univoci del ciclo di vita dello sviluppo software di ogni organizzazione. Questa pagina fornisce informazioni sugli strumenti disponibili per le pipeline CI/CD in Databricks. Per informazioni dettagliate sulle raccomandazioni e sulle procedure consigliate per CI /CD, vedere Procedure consigliate e flussi di lavoro CI/CD consigliati in Databricks.
Per una panoramica di CI/CD per i progetti di Machine Learning in Azure Databricks, vedere Come Databricks supporta CI/CD per Machine Learning?
Flusso ad alto livello
Un flusso comune per una pipeline CI/CD di Azure Databricks è:
-
Versione: archivia il codice e i notebook di Azure Databricks in un sistema di controllo della versione come Git. In questo modo è possibile tenere traccia delle modifiche nel tempo e collaborare con altri membri del team.
- I singoli utenti usano una cartella Git per creare e testare le modifiche prima di eseguirne il commit in un repository Git. Vedere CI/CD con le cartelle Git di Databricks.
- Facoltativamente, configurare le impostazioni Git del bundle.
-
Codice: sviluppare codice e unit test in un notebook di Azure Databricks nell'area di lavoro o in locale usando un IDE.
- Usare l'editor di Pipelines Lakeflow per sviluppare pipeline nell'area di lavoro.
- Usare l'estensione Databricks di Visual Studio Code per sviluppare e distribuire modifiche locali nelle aree di lavoro di Azure Databricks.
-
Build: Utilizzare le impostazioni dei bundle di asset di Databricks per costruire automaticamente determinati artefatti durante le distribuzioni.
- Configurare il mapping degli artefatti per la configurazione del pacchetto.
- Pylint esteso con il plug-in pylint di Databricks Labs consente di applicare standard di codifica e rilevare bug nei notebook di Databricks e nel codice dell'applicazione.
-
Distribuzione: distribuire le modifiche nell'area di lavoro di Azure Databricks usando i bundle di asset di Databricks con strumenti come Azure DevOps, GitHub Actions o Jenkins.
- Configurare le distribuzioni usando le modalità di distribuzione bundle.
- Per informazioni dettagliate sull'uso di Azure DevOps e Databricks, vedere Integrazione e recapito continui in Azure Databricks con Azure DevOps.
- Per esempi di GitHub Actions di Databricks, vedere GitHub Actions.
-
Test: sviluppare ed eseguire test automatizzati per convalidare le modifiche al codice.
- Usare strumenti come pytest per testare le integrazioni.
-
Esegui: utilizzare l'interfaccia a riga di comando di Databricks con i Databricks Asset Bundles per automatizzare l'esecuzione di processi nelle aree di lavoro di Azure Databricks.
- Esegui le risorse bundle utilizzando databricks bundle run.
- Monitoraggio: monitorare le prestazioni del codice e dei carichi di lavoro di produzione in Azure Databricks usando strumenti come il monitoraggio dei processi. Ciò consente di identificare e risolvere eventuali problemi che si verificano nell'ambiente di produzione.
Strumenti disponibili
Gli strumenti seguenti supportano i principi di base CI/CD: versione di tutti i file e unificare la gestione degli asset, definire l'infrastruttura come codice, isolare gli ambienti, automatizzare i test e monitorare e automatizzare i rollback.
| Zona | Usa questi strumenti quando vuoi... |
|---|---|
| Bundle di risorse di Databricks | Definire, distribuire ed eseguire risorse tramite programmazione, tra cui processi Lakeflow, pipeline dichiarative di Lakeflow Spark e stack MLOps, seguendo le migliori pratiche e flussi CI/CD. |
| Databricks Terraform Provider | Effettuare il provisioning e gestire le aree di lavoro e l'infrastruttura di Databricks usando Terraform. |
| Integrazione e distribuzione continue in Azure Databricks con Azure DevOps | Sviluppa una pipeline CI/CD per Azure Databricks utilizzando Azure DevOps. |
| Eseguire l'autenticazione con Azure DevOps in Azure Databricks | Eseguire l'autenticazione con Azure DevOps. |
| GitHub Actions | Includere un'azione GitHub sviluppata per Azure Databricks nel flusso CI/CD. |
| CI/CD con Jenkins su Azure Databricks | Sviluppare una pipeline CI/CD per Azure Databricks che usa Jenkins. |
| Orchestrare job di Lakeflow con Apache Airflow | Gestire e pianificare una pipeline di dati che usa Apache Airflow. |
| Principali del servizio per CI/CD | Usare le entità servizio, anziché gli utenti, con CI/CD. |
| Autenticare l'accesso ad Azure Databricks usando la federazione dei token OAuth | Utilizzare la federazione dell'identità del carico di lavoro per l'autenticazione nei processi CI/CD, eliminando la necessità dei segreti di Databricks e rendendolo il metodo più sicuro per autenticarsi su Databricks. |
Aggregazioni di asset di Databricks
I bundle di asset di Databricks sono l'approccio consigliato per CI/CD in Databricks. Usare i bundle di asset di Databricks per descrivere le risorse di Databricks come processi e pipeline come file di origine e aggregarli insieme ad altri asset per fornire una definizione end-to-end di un progetto distribuibile. Questi bundle di file possono essere controllati dall'origine ed è possibile usare l'automazione CI/CD esterna, ad esempio Github Actions, per attivare le distribuzioni.
I bundle includono molte funzionalità, ad esempio modelli personalizzati per l'applicazione della coerenza e delle procedure consigliate nell'organizzazione, nonché il supporto completo per la distribuzione dei file di codice e della configurazione per molte risorse di Databricks. La creazione di un bundle richiede una certa conoscenza della sintassi di configurazione del bundle.
Per consigli su come usare i bundle in CI/CD, vedere Procedure consigliate e flussi di lavoro CI/CD consigliati in Databricks.
Altri strumenti per il controllo del codice sorgente
In alternativa all'applicazione completa di CI/CD con Databricks Asset Bundles, Databricks offre opzioni solo per il source-control e la distribuzione di file di codice e notebook.
Cartella Git: le cartelle Git possono essere usate per riflettere lo stato di un repository Git remoto. È possibile creare una cartella Git per la produzione per gestire i file e i notebook di origine controllati dall'origine. Eseguire quindi manualmente il pull della cartella Git nello stato più recente oppure usare strumenti CI/CD esterni, ad esempio GitHub Actions, per eseguire il pull della cartella Git in fase di unione. Usare questo approccio quando non si ha accesso alle pipeline CI/CD esterne.
Questo approccio funziona per agenti di orchestrazione esterni, ad esempio Airflow, ma si noti che solo i file di codice, ad esempio notebook e bozze di dashboard, sono nel controllo del codice sorgente. Le configurazioni per processi o pipeline che eseguono asset nella cartella Git e le configurazioni per la pubblicazione dei dashboard non sono incluse nel controllo del codice sorgente.
Git con processi: Git con processi consente di configurare alcuni tipi di processo per l'uso di un repository Git remoto come origine per i file di codice. All'avvio di un'esecuzione di un processo, Databricks crea uno snapshot del repository ed esegue tutte le attività in tale versione. Questo approccio supporta solo attività di processo limitate e solo i file di codice (notebook e altri file) sono controllati dal codice sorgente. Le configurazioni dei processi, ad esempio le sequenze di attività, le impostazioni di calcolo e le pianificazioni non sono controllate dall'origine, rendendo questo approccio meno adatto per distribuzioni multi-ambiente, tra aree di lavoro.