FAQ sur les Declarative Automation Bundles

Cet article liste les questions fréquemment posées concernant les Declarative Automation Bundles (anciennement connus sous le nom de Databricks Asset Bundles).

Pourquoi Databricks Asset Bundles a-t-il été renommé Declarative Automation Bundles ?

Le nouveau nom Declarative Automation Bundles reflète plus précisément l'utilisation et les capacités des bundles. De plus, le terme assets a semé une certaine confusion car il a plus d'une signification chez Databricks. Ce changement de nom est non-majeur. La commande CLI bundle et toute votre configuration existante n'ont pas besoin d'être modifiées.

Comment utiliser les Declarative Automation Bundles dans le cadre de mon pipeline CI/CD sur Databricks ?

Vous pouvez utiliser Declarative Automation Bundles pour définir et gérer de manière programmatique les assets dans votre implémentation Databricks CI/CD, qui inclut généralement :

• Notebooks : les Notebooks Databricks sont souvent un élément clé des workflows de Data Engineering et de Data Science. Vous pouvez utiliser le contrôle de version pour les Notebooks, et également les valider et les tester dans le cadre d'un pipeline CI/CD. Vous pouvez exécuter des tests automatisés sur des Notebooks pour vérifier s'ils fonctionnent comme prévu.
• Bibliothèques : gérez les dépendances de bibliothèque nécessaires à l'exécution de votre code déployé. Utilisez le contrôle de version sur les bibliothèques et incluez-les dans les tests et la validation automatisés.
• Workflows : Les Lakeflow Jobs sont composés de Jobs qui vous permettent de planifier et d'exécuter des tâches automatisées à l'aide de Notebooks ou de Jobs Spark.
• Pipelines de données : Vous pouvez également inclure des pipelines de données dans l'automatisation CI/CD, en utilisant Lakeflow Pipelines pour déclarer des pipelines de données.
• Infrastructure : La configuration de l'infrastructure comprend les définitions et les informations de provisionnement pour les clusters, les Workspace et le stockage pour les environnements cibles. Les changements d'infrastructure peuvent être validés et testés dans le cadre d'un pipeline CI/CD, garantissant qu'ils sont cohérents et sans erreur.

Pourquoi est-il nécessaire d'avoir des environnements cibles de développement et de production séparés ?

Des environnements de développement et de production distincts vous permettent de :

• Isolez en toute sécurité les modifications de développement afin qu'elles n'affectent pas accidentellement la production.
• Prévenez la duplication de code en personnalisant les ressources à appliquer à un environnement cible spécifique.
• Rationalisez et simplifiez le CI/CD avec une configuration spécifique à l'environnement, telle que les chemins de base de données, les alertes et les contrôles d'accès.
• Réutiliser les workflows au sein des équipes et des environnements.

Utilisez des cibles pour définir les environnements de déploiement de bundles. Voir les cibles.

Comment rendre mes bundles cohérents au sein de mon organisation ?

Utilisez des modèles de bundle pour une structure cohérente, afin de réduire les erreurs de configuration et de promouvoir les meilleures pratiques. Vous pouvez utiliser les Template de bundle par default ou créer vos propres Template de bundle personnalisés. Consultez les modèles de projet Declarative Automation Bundles.

Il y a beaucoup de répétitions dans mes bundles, comme les mêmes définitions de clusters. Quelle est la meilleure façon de gérer cela ?

Les variables personnalisées sont le meilleur moyen de gérer les répétitions, ainsi que les paramètres spécifiques au contexte. Consultez les variables personnalisées.

Quelles sont les meilleures pratiques lors de l'utilisation de bundles dans mon flux de déploiement ?

Databricks vous recommande de :

• Passez des déploiements manuels à une automatisation fiable grâce à des workflows intégrés à Git.
• Validez avant de déployer un bundle en utilisant databricks bundle validate dans votre pipeline CI/CD.
• Séparez les étapes de déploiement afin de garantir que les modifications soient examinées et intentionnelles.
• Paramétrer les environnements (dev, staging, prod) avec des substitutions pour isoler les modifications.
• Exécutez des tests d'intégration après le déploiement pour détecter les problèmes à un stade précoce.
• Utilisez GitHub Actions, Azure DevOps ou GitLab CI pour Trigger des déploiements lors d'un commit ou d'une Merge de PR.
• Suivez ce qui est déployé, où et quand, afin que chaque déploiement corresponde à un commit et à une version de bundle.

Puis-je transférer des jobs, pipelines, tableaux de bord et autres objets Databricks existants dans mon bundle ?

Oui. Utilisez la commande databricks bundle generate pour générer un fichier de configuration pour un Job, un pipeline ou un tableau de bord existant dans votre bundle local, puis utilisez databricks bundle deployment bind pour lier la ressource du bundle à la ressource correspondante dans le workspace. C'est l'idéal pour intégrer les workflows existants dans un développement structuré et versionné. La liaison résout également les chemins relatifs en références de Workspace absolues, ce qui évite les erreurs de chemin.

Consultez Migrer les ressources existantes vers un bundle.

Comment tester mon bundle de manière itérative ?

Vous pouvez développer plus rapidement grâce aux déploiements et exécutions itératifs :

• Validez avant de déployer
• Déployer par incréments
• Exécutez uniquement ce qui est nécessaire
• Modifier et répéter

Cela accélère les tests et le debugging, réduit le changement de contexte, permet une itération plus sûre et plus rapide sans redéploiements complets, et renforce la discipline à mesure que vous progressez vers la production.