CI/CD sur Databricks
Les fonctionnalités d'intégration et de livraison continues (CI/CD) font référence au processus de développement et de livraison d'outils/solutions/technologies/plateformes en cycles courts et fréquents grâce à l'utilisation de pipelines d'automatisation. Le CI/CD est courant dans le développement de logiciels, et devient de plus en plus nécessaire en Data Engineering et en Data Science. En automatisant la création, le test et le déploiement du code, les équipes de développement livrent des versions de manière plus fiable qu'avec les processus manuels.
Databricks fournit des outils pour développer des pipelines CI/CD qui prennent en charge des approches pouvant différer entre les organisations en raison des aspects uniques de leurs cycles de vie de développement logiciel. Cette page fournit des informations sur les outils disponibles pour les pipelines CI/CD sur Databricks.
Pour plus de détails sur les recommandations et les meilleures pratiques de développement et de CI/CD, consultez les éléments suivants :
- Workflows CI/CD sur Databricks
- Bonnes pratiques de développement sur Databricks
- Comment Databricks prend-il en charge le CI/CD pour le Machine Learning ?
Flux de haut niveau
Un workflow courant pour un pipeline CI/CD Databricks est :
-
Version : Stockez votre code Databricks et vos Notebooks dans un système de contrôle de version comme Git. Cela vous permet de suivre les changements au fil du temps et de collaborer avec d'autres membres de l'équipe.
- Les utilisateurs individuels utilisent un dossier Git pour créer et tester les modifications avant de les commit dans un repository Git. Consultez CI/CD avec les dossiers Git Databricks.
- Vous pouvez configurer en option les paramètres Git du bundle.
-
Code : Développez du code et des tests unitaires dans un notebook Databricks dans le Workspace ou localement à l'aide d'un IDE.
- Utilisez l'LakeFlow Pipelines Editor pour développer des pipelines dans le workspace.
- Utilisez l'extension Visual Studio Code Databricks pour développer et déployer des modifications locales vers les Workspaces Databricks.
-
Création : utilisez les paramètres des Declarative Automation Bundles pour créer automatiquement certains artefacts lors des déploiements.
- Configurez le mappage des artefacts de configuration du bundle.
- Pylint, étendu avec le plugin pylint de Databricks Labs, aide à appliquer les standards de codage et à détecter les bogues dans vos notebooks Databricks et votre code d’application.
-
Déploiement : Déployer des modifications dans le Databricks Workspace à l’aide de bundles d’automatisation déclaratifs avec des outils comme Azure DevOps, GitHub Actions ou Jenkins.
- Configurez les déploiements à l'aide des modes de déploiement de bundle.
- Pour plus de détails sur l’utilisation d’Azure DevOps et de Databricks, consultez Intégration et livraison continues sur Databricks avec Azure DevOps.
- Pour des exemples de Databricks GitHub Actions, consultez GitHub Actions.
- Pour utiliser Jenkins Pipeline avec Databricks, consultez CI/CD avec Jenkins sur Databricks.
-
Test : Développez et exécutez des tests automatisés pour valider les modifications de votre code.
- Utilisez des outils comme pytest pour tester vos intégrations.
-
Exécution : Utilisez la CLI Databricks avec des bundles d'automatisation déclarative pour automatiser les exécutions dans vos workspaces Databricks.
- Exécutez les ressources du bundle à l'aide de databricks bundle run.
-
Surveiller : Surveillez les performances de votre code et de vos charges de travail de production dans Databricks à l'aide d'outils tels que le monitoring des Jobs. Cela vous aide à identifier et à résoudre les problèmes qui surviennent dans votre environnement de production.
Outils disponibles
Les outils suivants prennent en charge les principes fondamentaux de CI/CD : versionner tous les fichiers et unifier la gestion des assets, définir l'infrastructure en tant que code, isoler les environnements, automatiser les tests, et surveiller et automatiser les restaurations.
Zone (Area) | Utilisez ces outils lorsque vous souhaitez… |
|---|---|
Définissez, déployez et exécutez par programme des Ressources Databricks, y compris les Lakeflow Jobs, les LakeFlow Pipelines et les Stacks MLOps, en utilisant les meilleures pratiques et les flux CI/CD. | |
Provisionnez et gérez les Workspaces Databricks et l'infrastructure à l'aide de Terraform. Pour plus de détails sur le moment d'utiliser le fournisseur Terraform Databricks au lieu des Declarative Automation Bundles, consultez Outils de développement local. | |
Intégration et livraison continues sur Databricks à l'aide d'Azure DevOps | Développer un pipeline CI/CD pour Databricks qui utilise Azure DevOps. |
Incluez une GitHub Action développée pour Databricks dans votre flux CI/CD. | |
Développer un pipeline CI/CD pour Databricks qui utilise Jenkins. | |
Gérez et planifiez une pipeline de données qui utilise Apache Airflow. | |
Utilisez les Service Principals, au lieu des utilisateurs, avec CI/CD. | |
Authentifier l'accès à Databricks à l'aide de la fédération de jetons OAuth | Utilisez la fédération d'identités de charge de travail pour l'authentification CI/CD, ce qui élimine le besoin de secrets Databricks, en faisant ainsi le moyen le plus sécurisé de s'authentifier auprès de Databricks. |
Declarative Automation Bundles
Les Declarative Automation Bundles sont l'approche recommandée pour le CI/CD sur Databricks. Utilisez les Declarative Automation Bundles pour décrire les ressources Databricks, telles que les jobs et les pipelines, en tant que fichiers source, et regroupez-les avec d'autres assets afin de fournir une définition de bout en bout d'un projet déployable. Ces bundles de fichiers peuvent être gérés en gestion de versions, et vous pouvez utiliser une automatisation CI/CD externe telle que GitHub Actions pour Trigger les déploiements.
Les Bundles incluent de nombreuses fonctionnalités telles que des Templates personnalisés pour faire respecter la cohérence et les meilleures pratiques au sein de votre organisation, et un support complet pour le déploiement des fichiers de code et de la configuration pour de nombreuses ressources Databricks. L'élaboration d'un bundle nécessite une certaine connaissance de la syntaxe de configuration du bundle.
Pour des recommandations sur l'utilisation des bundles en CI/CD, consultez les workflows CI/CD sur Databricks et les bonnes pratiques des développeurs sur Databricks.
Autres outils de contrôle de version
Plutôt que d'appliquer un CI/CD complet avec les Declarative Automation Bundles, Databricks propose des options pour gérer et déployer uniquement les fichiers de code et les notebooks.
-
Dossier Git: les dossiers Git peuvent être utilisés pour refléter l'état d'un repository Git distant. Vous pouvez créer un dossier Git pour la production afin de gérer les fichiers source et les notebooks sous contrôle de version. Ensuite, extrayez manuellement le dossier Git vers le dernier état, ou utilisez des outils CI/CD externes, tels que GitHub Actions, pour extraire le dossier Git lors de la Merge. Utilisez cette approche lorsque vous n'avez pas accès à des pipelines CI/CD externes.
Cette approche fonctionne pour les orchestrateurs externes tels qu'Airflow, mais notez que seuls les fichiers de code, tels que les notebooks et les brouillons de tableaux de bord, sont sous contrôle de version. Les configurations des Jobs ou des pipelines qui exécutent des assets dans le dossier Git et les configurations de publication de tableaux de bord ne sont pas sous contrôle de version.
-
Git avec les Jobs: Git avec les Jobs vous permet de configurer certains types de Jobs pour utiliser un repository Git distant comme source pour les fichiers de code. Lorsqu'un Job commence, Databricks prend un instantané du repository et exécute toutes les tâches par rapport à cette version. Cette approche ne prend en charge que des tâches de Job limitées, et seuls les fichiers de code (Notebooks et autres fichiers) sont gérés par le contrôle de source. Les configurations de Job, telles que les séquences de tâches, les paramètres de compute et les planifications, ne sont pas contrôlées par la source, ce qui rend cette approche moins adaptée aux déploiements multi-environnements et inter-Workspace.