Questions fréquentes (FAQ) sur les paquets d'automatisation déclarative

Cet article répertorie les questions fréquemment posées sur les Bundles d'Automatisation Déclarative (anciennement connus sous le nom de Databricks Asset Bundles).

Pourquoi Databricks Asset Bundles a-t-il été renommé en Bundles d'Automation Déclaratifs ?

Le nouveau nom Declarative Automation Bundles reflète plus précisément l’utilisation et les capacités des bundles. En outre, le terme ressources a causé une certaine confusion, car elle a plusieurs significations dans Databricks. Cette modification de nom n’est pas cassant. La bundle commande CLI et toute votre configuration existante n’ont pas besoin d’être modifiées.

Comment puis-je utiliser des bundles d'automatisation déclaratifs dans le cadre de mon pipeline CI/CD sur Azure Databricks ?

Vous pouvez utiliser Bundles d'Automation Déclarative pour définir et gérer de manière programmatique des ressources dans votre implémentation CI/CD Azure Databricks, qui inclut généralement :

• Notebooks : les notebooks Azure Databricks font souvent partie intégrante des workflows d’ingénierie des données et de science des données. Vous pouvez utiliser le contrôle de version pour les notebooks, puis 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 requises pour exécuter 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.
• Flux de travail : Les jobs Lakeflow comprennent des jobs qui permettent de planifier et 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 les Lakeflow Spark Declarative Pipelines, le cadre dans Databricks pour déclarer des pipelines de données.
• Infrastructure : la configuration de l’infrastructure inclut des définitions et des informations d’approvisionnement pour les clusters, les espaces de travail et le stockage pour les environnements cibles. Les modifications d’infrastructure peuvent être validées et testées dans le cadre d’un pipeline CI/CD, ce qui garantit qu’elles sont cohérentes et sans erreur.

Pourquoi dois-je disposer d’environnements de développement et de cible de production distincts ?

Les environnements de développement et de produit distincts vous permettent de :

• Isolez en toute sécurité les modifications de développement afin qu’elles n’affectent pas accidentellement la production.
• Empêchez la duplication de code en personnalisant les ressources à appliquer à un environnement cible spécifique.
• Optimisez et simplifiez le CI/CD avec une configuration spécifique à l'environnement, comme les chemins de base de données, les alertes et les contrôles d'accès.
• Réutilisez les flux de travail entre les équipes et les environnements.

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

Comment rendre mes offres groupées cohérentes dans mon organisation ?

Utilisez des modèles groupés pour une structure cohérente, pour réduire les erreurs d’installation et promouvoir les meilleures pratiques. Vous pouvez utiliser des modèles d’offre groupée par défaut ou créer vos propres modèles d’offre groupée personnalisée. Consultez les modèles de projet de Bundles d'automatisation déclaratifs.

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

Les variables personnalisées sont la meilleure façon 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 d’offres groupées dans mon flux de déploiement ?

Databricks vous recommande :

• Passez des déploiements manuels à une automatisation fiable à l’aide de flux de travail intégrés à Git.
• Validez avant de déployer un bundle en utilisant databricks bundle validate dans votre pipeline CI/CD.
• Étapes de déploiement distinctes pour vous assurer que les modifications sont examinées et intentionnelles.
• Paramétrez des environnements (dev, intermédiaire, prod) avec des remplacements pour isoler les modifications.
• Exécutez des tests d’intégration après le déploiement pour détecter les problèmes au début.
• Utilisez GitHub Actions, Azure DevOps ou GitLab CI pour déclencher des déploiements lors d'un commit ou de la fusion d'une PR.
• Suivez ce qui est déployé, où et à quel moment, afin que chaque déploiement corresponde à un commit et à une version de bundle.

Puis-je porter des travaux, des pipelines, des tableaux de bord et d’autres objets Databricks existants dans mon bundle ?

Yes. Utilisez la databricks bundle generate commande pour générer un fichier de configuration pour un travail, un pipeline ou un tableau de bord existant dans votre bundle local, puis pour databricks bundle deployment bind lier la ressource groupée à la ressource correspondante dans l’espace de travail. Cela est idéal pour intégrer des flux de travail existants dans un développement structuré et versionné. Le processus de liaison résout également les chemins relatifs en références d’espace de travail absolues, ce qui évite les erreurs de chemin d’accès.

Consultez Migrer des ressources existantes vers un bundle.

Comment tester mon bundle de façon itérative ?

Vous pouvez développer plus rapidement avec des déploiements itératifs et des exécutions :

• Valider avant le déploiement
• Déployer de manière incrémentielle
• Exécuter uniquement ce qui est nécessaire
• Modifier et répéter

Cela accélère les tests et le débogage, réduit le changement de contexte, permet une itération plus sûre et plus rapide sans redéploiements complets et applique la discipline au fur et à mesure que vous passez à la production.