CI/CD sur Azure Databricks

L’intégration continue et la livraison continue (CI/CD) font référence au processus de développement et de livraison de logiciels en bref et fréquents cycles par le biais de l’utilisation de pipelines d’automatisation. CI/CD est courant dans le développement de logiciels et devient de plus en plus nécessaire dans l’ingénierie des données et la science des données. En automatisant la génération, le test et le déploiement de code, les équipes de développement fournissent des versions plus fiables qu’avec des processus manuels.

Databricks fournit des outils pour développer des pipelines CI/CD qui prennent en charge des approches qui peuvent différer légèrement de l’organisation à l’organisation en raison d’aspects uniques du cycle de vie du développement logiciel de chaque organisation. Cette page fournit des informations sur les outils disponibles pour les pipelines CI/CD sur Databricks. Pour plus d’informations sur les recommandations ci/CD et les bonnes pratiques, consultez Meilleures pratiques et flux de travail CI/CD recommandés sur Databricks.

Pour obtenir une vue d’ensemble de CI/CD pour les projets Machine Learning sur Azure Databricks, consultez Comment Databricks prend-il en charge CI/CD pour le Machine Learning ?.

Flux de haut niveau

Un flux courant pour un pipeline CI/CD Azure Databricks est le suivant :

1. Version : Stockez votre code et vos notebooks Azure Databricks dans un système de contrôle de version tel que Git. Cela vous permet de suivre les modifications 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 valider dans un dépôt Git. Consultez CI/CD avec les dossiers Git de Databricks.
   • Configurez éventuellement les paramètres Git de bundle.
2. Code : développez du code et des tests unitaires dans un notebook Azure Databricks dans l’espace de travail ou localement à l’aide d’un IDE.
   • Utilisez l’Éditeur de pipelines Lakeflow pour développer des pipelines dans l’espace de travail.
   • Utilisez l’extension Databricks Visual Studio Code pour développer et déployer des modifications locales dans des espaces de travail Azure Databricks.
3. Build : utilisez les paramètres Databricks Asset Bundles pour générer automatiquement certains artefacts pendant les déploiements.
   • Configurez le mappage de la configuration du bundle des artefacts.
   • Pylint étendu avec le plug-in Pylint Databricks Labs permet d’appliquer des normes de codage et de détecter les bogues dans vos notebooks Databricks et le code d’application.
4. Déployer : déployez des modifications dans l’espace de travail Azure Databricks à l’aide de Bundles de ressources Databricks avec des outils tels qu’Azure DevOps, GitHub Actions ou Jenkins.
   • Configurez les déploiements à l’aide des modes de déploiement de bundle.
   • Pour plus d’informations sur l’utilisation d’Azure DevOps et de Databricks, consultez Intégration et livraison continues sur Azure Databricks à l’aide d’Azure DevOps.
   • Pour obtenir des exemples Databricks GitHub Actions, consultez GitHub Actions.
5. Test : développez et exécutez des tests automatisés pour valider vos modifications de code.
   • Utilisez des outils comme pytest pour tester vos intégrations.
6. Exécuter : utilisez l’interface CLI Databricks avec les bundles de ressources Databricks pour automatiser les exécutions dans vos espaces de travail Azure Databricks.
   • Exécutez les ressources du bundle à l'aide de databricks bundle run.
7. Moniteur : surveillez les performances de vos charges de travail de code et de production dans Azure Databricks à l’aide d’outils tels que la surveillance des travaux. Cela vous permet d’identifier et de résoudre les problèmes qui surviennent dans votre environnement de production.

Outils disponibles

Les outils suivants prennent en charge les principes fondamentaux CI/CD : versionr tous les fichiers et unifier la gestion des ressources, définir l’infrastructure en tant que code, isoler les environnements, automatiser les tests et surveiller et automatiser les restaurations.

Ensembles de ressources Databricks

Les bundles de ressources Databricks sont l’approche recommandée pour CI/CD sur Databricks. Utilisez databricks Asset Bundles pour décrire les ressources Databricks, telles que les travaux et les pipelines en tant que fichiers sources, et les regrouper avec d’autres ressources pour fournir une définition de bout en bout d’un projet déployable. Ces ensembles de fichiers peuvent être contrôlés par la source et vous pouvez utiliser l’automatisation CI/CD externe comme Github Actions pour déclencher des déploiements.

Les offres groupées incluent de nombreuses fonctionnalités telles que des modèles personnalisés pour appliquer la cohérence et les meilleures pratiques au sein de votre organisation, et une prise en charge complète du déploiement des fichiers de code et de la configuration pour de nombreuses ressources Databricks. La création d’un bundle nécessite une connaissance de la syntaxe de configuration de l’offre groupée.

Pour obtenir des recommandations sur l’utilisation de bundles dans CI/CD, consultez les meilleures pratiques et les flux de travail CI/CD recommandés sur Databricks.

Autres outils pour le contrôle de code source

Comme alternative à l'application complète du CI/CD avec des paquets de ressources Databricks, Databricks offre des options pour uniquement le contrôle de version du code source et le déploiement des fichiers de code et des notebooks.

• Dossier Git : les dossiers Git peuvent être utilisés pour refléter l’état d’un dépôt Git distant. Vous pouvez créer un dossier Git pour la production pour gérer les fichiers et notebooks sources contrôlés par la source. Ensuite, extrayez manuellement le dossier Git à l’état le plus récent ou utilisez des outils CI/CD externes tels que GitHub Actions pour extraire le dossier Git lors de la fusion. Utilisez cette approche lorsque vous n’avez pas accès aux pipelines CI/CD externes.

  Cette approche fonctionne pour les orchestrateurs externes tels qu'Airflow, mais sachez que seuls les fichiers de code, tels que les notebooks et les brouillons de tableau de bord, sont dans la gestion de code source. Les configurations pour les travaux ou les pipelines qui exécutent des ressources dans le dossier Git et les configurations pour la publication de tableaux de bord ne sont pas dans le contrôle de code source.

• Git avec des travaux : Git avec des travaux vous permet de configurer certains types de travaux afin d’utiliser un référentiel Git distant comme source pour les fichiers de code. Lorsqu’une exécution de travail commence, Databricks prend un instantané du référentiel et exécute toutes les tâches sur cette version. Cette approche prend uniquement en charge des tâches de travail limitées, et seuls les fichiers de code (notebooks et autres fichiers) sont contrôlés par la source. Les configurations de travail telles que les séquences de tâches, les paramètres de calcul 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-espaces de travail.