Tutoriel : Comment déployer en toute sécurité et à grande échelle les modifications de tableaux de bord AI/BI avec les bundles d'automatisation déclarative

L'idée qu'une réunion de conseil d'administration puisse commencer par un tableau de bord truffé d'erreurs devrait empêcher les équipes d'analystes de dormir. Tout comme le fait de découvrir, après coup, qu'un plan de recrutement, un lancement de produit ou des prévisions de chiffre d'affaires reposaient sur une métrique incorrecte. Ou qu'une équipe d'assistance a accordé beaucoup trop de remboursements parce qu'un tableau de bord présentait de manière erronée l'historique des achats d'un client.

Ces défaillances sont rarement dues à une mauvaise analyse. Comme pour tout système de production, elles découlent souvent de mises à jour manuelles des tableaux de bord au fil de l'évolution des modèles de données et des exigences, sans gestion des versions, sans processus de révision fiable ou sans méthode reproductible pour déployer les modifications d'un environnement à l'autre.

Cet article de blog défend une idée simple : les tableaux de bord de niveau production qui guident l'entreprise doivent être gérés avec la même rigueur que le code de production. Puisque Databricks AI/BI s'exécute sur la même Data Intelligence Platform que vos pipelines de données et votre couche de gouvernance, les équipes peuvent également appliquer ces mêmes pratiques de production (contrôle de version, configuration spécifique à l'environnement et déploiement contrôlé) aux tableaux de bord.

Pour rendre cela concret, nous allons vous montrer comment les analystes peuvent utiliser les fonctionnalités de niveau production de Databricks sans changer leur façon de concevoir les tableaux de bord au quotidien.

Plus précisément, nous verrons comment ce flux vous permet de :

• Examiner et approuver chaque modification apportée à un tableau de bord
• Suivre l'historique d'un tableau de bord et associer les modifications de code aux exigences de l'entreprise
• Restaurer une version antérieure d'un tableau de bord

Prérequis

Ce flux de travail nécessite une configuration d'infrastructure unique que la plupart des organisations ont déjà mise en place. Si ce n'est pas votre cas, demandez à votre équipe DevOps ou informatique interne de vous aider à configurer :

• Au moins deux espaces de travail Databricks (par exemple, un espace de développement et un de production) pour concevoir, tester et déployer des tableaux de bord
• Des dossiers basés sur Git dans Databricks (AWS | Azure | GCP), utilisés pour gérer les versions des définitions de tableaux de bord
• Des bundles d'automatisation déclaratifs (DABs) (AWS | Azure | GCP) configurés pour le projet

Introduction : un flux de travail structuré pour déployer les modifications de tableaux de bord en toute sécurité

Nous allons passer en revue un scénario réaliste : vous possédez un tableau de bord Sales Performance utilisé chaque semaine par la direction financière et commerciale. À l'origine, il s'agissait d'un projet de stagiaire créé directement dans un espace de travail, mais il a évolué au fil du temps et est désormais utilisé lors de plusieurs réunions de direction.

Un changement de priorités lors d'une réunion du conseil d'administration apporte une nouvelle exigence : la Finance doit désormais suivre les montants des ventes engagés et non engagés, en remplacement d'une métrique de ventes agrégée unique, et le tableau de bord doit refléter cette nouvelle définition avant la prochaine révision des prévisions.

Ces valeurs alimentent directement des décisions commerciales réelles, notamment le calcul des rémunérations et des bonus. Mettons donc ce tableau de bord sur une voie de déploiement rigoureuse pour la toute première fois.

Étape 1 : Ajouter le tableau de bord dans un bundle d'automatisation déclaratif

Avant de commencer le processus, collaborez avec votre équipe informatique pour configurer des outils de code de base : un dépôt Git contenant un « bundle d'automatisation déclaratif » vide, et des scripts CI/CD pour déployer automatiquement le bundle.

Un dépôt Git est un outil permettant de suivre les modifications de fichiers. Pour commencer, nous devons le connecter à Databricks afin de pouvoir suivre les modifications apportées à la configuration du tableau de bord. Depuis l'espace de travail Databricks, créez un dossier Git et collez l'URL du dépôt dans la boîte de dialogue de configuration. Cela permet à Databricks de reconnaître le dépôt et de nous autoriser à y ajouter le tableau de bord à l'étape suivante.

Un bundle d'automatisation déclaratif est un moyen de regrouper des fichiers de code (dans ce cas, un tableau de bord). Si le dépôt contient déjà un bundle, celui-ci est automatiquement détecté et peut être ouvert à l'aide de l'icône de flèche. Sinon, un nouveau bundle peut être créé à partir du menu Créer dans le dossier Git.

Dans l'éditeur de bundles de ressources (Asset Bundle), vous pouvez ajouter des composants nouveaux et existants au bundle actuellement vide. Pour inclure le tableau de bord, ouvrez le menu Ajouter et sélectionnez Ajouter un tableau de bord existant. Après l'avoir ajouté, vous verrez le tableau de bord apparaître dans le dossier src en tant que partie du bundle.

À partir de ce moment, le tableau de bord est géré comme une ressource déployable, ce qui facilite le déploiement du même tableau de bord dans les espaces de travail de développement, de test et de production.

Enfin, validez (commit) le tableau de bord dans le dépôt. Cela permet de capturer l'état actuel du tableau de bord comme référence et d'établir un point de départ clair pour le suivi et la révision des modifications futures.

Vous verrez que le tableau de bord a été ajouté au dépôt, ainsi que quelques fichiers de configuration générés automatiquement (se terminant par .yml). Ces fichiers décrivent comment le tableau de bord doit être déployé dans différents environnements ; vous n'avez pas besoin de les modifier.

Ajoutez une courte note décrivant ce que vous avez fait dans le champ message de validation (commit message), puis sélectionnez Valider et pousser (Commit & Push). Cela crée un point de contrôle pour le tableau de bord (un état stable connu auquel vous pourrez revenir plus tard) afin que les futures modifications puissent être comparées, examinées et déployées en toute sécurité.

Étape 2 : Mettre à jour le tableau de bord

Maintenant que le tableau de bord existant a été validé, vous pouvez commencer à y apporter des modifications sans affecter ce qui est déjà en production, et Git suivra les modifications spécifiques que vous avez effectuées.

La pratique générale consiste à créer une branche Git, c'est-à-dire une version du tableau de bord sur laquelle travailler sans affecter les autres. Vous pouvez le faire via le bouton Créer une branche, puis lui donner un nom descriptif comme votre nom, la fonctionnalité ou un numéro de ticket associé à la modification. Considérez cela comme une version privée pour votre mise à jour : vous pouvez modifier, tester et affiner le tableau de bord librement, puis décider indépendamment du moment où vos modifications sont prêtes à être examinées et déployées.

Vous pouvez maintenant modifier le tableau de bord ! Dans ce cas, vous allez modifier le chiffre des ventes en haut à gauche pour ajouter les compteurs de ventes non engagées et engagées (le bleu et le rouge en gras ont été choisis pour une meilleure visibilité).

Vous remarquerez que l'expérience de création ne change pas : effectuez ces modifications comme vous le feriez normalement à l'aide de l'éditeur UI du tableau de bord.

Une fois que le tableau de bord s'affiche correctement en développement, vous êtes prêt à procéder pour envoyer les modifications en production. Utilisez le même bouton Git en haut que précédemment pour enregistrer ces modifications avec un court message de commit.

Étape 3 : Examiner la modification

Ensuite, vous débloquez un autre avantage clé de ce flux de travail : un espace permettant aux autres d'examiner les modifications et de donner leur avis avant qu'elles n'atteignent la production. Le fait de requérir l'avis d'une seconde personne est une bonne pratique générale, mais cela crée tout aussi bien un espace sans enjeu pour discuter d'idées, valider des hypothèses et affiner la modification avant qu'elle n'impacte les rapports.

Pour lancer l'examen, créez une Pull Request (PR) chez votre fournisseur Git, ce qui correspond essentiellement à une page de révision pour la mise à jour du tableau de bord. Le réviseur peut voir exactement ce qui a changé, laisser des commentaires pour que vous puissiez y répondre et approuver la mise à jour une fois que tout semble correct.

Pendant l'examen, le tableau de bord de production reste inchangé. Ce n'est qu'une fois que les commentaires ont été pris en compte et que la modification est approuvée qu'elle progresse.

Bien que les modifications du tableau de bord soient stockées et suivies sous forme de fichiers de configuration en arrière-plan, il est souvent difficile de comprendre ce qui a réellement changé. C'est pourquoi la plupart des équipes utilisent une petite automatisation pour déployer automatiquement une version de test temporaire du tableau de bord pour examen à chaque fois qu'une PR est ouverte. De cette façon, les réviseurs peuvent voir les métriques, les calculs et les mises en page proposés en contexte avant que quoi que ce soit n'atteigne la production, et détecter les problèmes de logique de données ou d'UI. Le fait que le développeur ou le réviseur inclue des captures d'écran ou des liens vers le tableau de bord de test directement dans la PR permet également d'obtenir des retours plus rapides et plus fiables.

Les réviseurs peuvent ajouter des commentaires et approuver, ce qui est enregistré pour que la modification soit plus facile à comprendre par la suite.

Étape 4 : Déployer le tableau de bord en production à l'aide du bundle

Une fois la modification approuvée, vous êtes prêt à déployer le tableau de bord en production.

Les tableaux de bord nécessitent souvent des paramètres différents en production et en développement - par exemple, pointer vers un catalogue ou un schéma de production au lieu d'un jeu de données de développement, ou utiliser un SQL warehouse différent.

La bonne nouvelle est que ces différences sont prévues et gérées dans le cadre du processus de déploiement.

Lorsque vous avez ajouté le tableau de bord au Asset Bundle, Databricks a généré un petit fichier de configuration .yml qui capture ces paramètres spécifiques à l'environnement. Ce fichier vous permet de surcharger les valeurs par environnement sans modifier la logique du tableau de bord elle-même. Dans notre cas, nous avons spécifié que le catalogue utilisé par le tableau de bord en production doit être différent de celui de test, en utilisant une valeur ${variable} pour le nom du catalogue.

Enfin, le fichier databricks.yml lie toutes les ressources du bundle entre elles et définit quel catalogue est utilisé dans chaque environnement, ce qui facilite la gestion de déploiements cohérents dans les espaces de travail de développement, de test et de production.

Une fois la Pull Request approuvée et fusionnée dans la branche principale, votre automatisation de déploiement s'exécute et utilise les valeurs spécifiques à l'environnement définies dans databricks.yml. Le même code de tableau de bord est réutilisé dans tous les espaces de travail, tandis que les paramètres tels que le catalogue, le schéma et le warehouse sont appliqués en fonction de l'environnement cible. Cela évite d'avoir à maintenir des copies de tableaux de bord distinctes pour chaque espace de travail et garantit que les modifications se comportent de manière prévisible partout.

Pour la plupart des fournisseurs Git, vous pourrez voir l'automatisation du déploiement sur la pull request afin de suivre le déploiement et de confirmer sa finalisation (ou de détecter s'il rencontre un problème). Si un problème survient, le déploiement s'arrête sans affecter le tableau de bord de production existant pour vous permettre de le dépanner. Une fois le déploiement réussi, le tableau de bord mis à jour est en ligne en production et prêt pour les parties prenantes !

Bonus 1 : Et si vous souhaitez inspecter l'historique ?

Une fois la mise à jour du tableau de bord en ligne, vous devrez peut-être comprendre l'historique de ce qui a changé, quand et pourquoi. L'un des avantages de ce flux est que la modification est désormais traçable. Au lieu d'une modification ponctuelle effectuée directement dans un espace de travail, elle apparaît sous la forme d'une séquence de versions enregistrées.

Chaque entrée représente une mise à jour du tableau de bord, ainsi que l'auteur et l'horodatage. Vous pouvez ouvrir n'importe quelle entrée pour examiner les modifications et revenir en arrière si nécessaire.

Bonus 2 : Et si vous devez annuler une modification ?

Même avec un examen et des tests approfondis, des problèmes peuvent toujours survenir, comme un tableau de bord qui ne se charge pas ou une définition de métrique qui s'avère incorrecte.

Comme le tableau de bord est géré via ce flux de travail, vous pouvez revenir à une version stable connue en utilisant le même processus contrôlé que celui utilisé pour déployer la mise à jour.

Commencez par ouvrir l'historique des modifications du tableau de bord dans le dépôt et localisez la mise à jour que vous souhaitez annuler. À partir de là, vous pouvez examiner ce qui a été modifié pour confirmer que vous annulez la bonne modification avant de continuer.

Depuis les détails de la modification, suivez le lien pour revenir à la page d'examen. Pour annuler la mise à jour, sélectionnez Revert. Cela crée une nouvelle modification d'annulation qui inverse uniquement cette mise à jour spécifique, rétablissant le tableau de bord dans sa logique précédente tout en conservant intact le reste de l'historique du tableau de bord.

Une fois la modification fusionnée dans la branche principale, la même automatisation qui a déployé le tableau de bord en production le ramènera à sa version précédente. Cela signifie que vous pouvez réagir à une panne ou à un problème de calcul à fort impact en quelques minutes, sans contourner les contrôles déjà en place.

Bonus 3 : Et si vos sources de données sont mises à jour ?

La plupart des tableaux de bord sont étroitement liés à leurs sources de données, ce qui signifie que les mises à jour d'un tableau de bord sont souvent étroitement liées aux mises à jour des pipelines. La bonne nouvelle est que les Asset Bundles sont conçus pour regrouper les composants associés dans un seul package.

Cela garantit qu'une modification du modèle de données en amont ne vous prenne jamais au dépourvu, et lorsque les modifications de visualisation nécessitent des mises à jour du modèle de données, vous pouvez déployer les deux modifications en un seul déploiement.

Conclusion

Traiter les tableaux de bord AI/BI comme des produits de données prêts pour la production est essentiel pour prendre des décisions commerciales fiables et atténuer les risques. Dans ce workflow, un ensemble restreint d'étapes supplémentaires rend les modifications des tableaux de bord visibles, vérifiables et réversibles, sans changer votre façon de créer des tableaux de bord au quotidien.

En gérant les tableaux de bord avec Git et Declarative Automation Bundles, les équipes établissent un workflow routinier et prévisible pour les mises à jour : effectuer la modification, la réviser, la tester et la déployer. Le même processus s'applique, que la mise à jour soit un simple ajustement visuel ou une modification importante de la logique métier.

Avec une discipline de déploiement appropriée, les modifications des tableaux de bord cessent d'être une source de risque pour devenir une source d'informations fiable qui évolue avec l'entreprise, même dans des situations à enjeux élevés comme une réunion du conseil d'administration.

En savoir plus + Étapes suivantes

Si vous êtes inspiré et souhaitez approfondir les éléments utilisés dans ce workflow, voici quelques ressources utiles pour continuer :

• « Stratégie de branching » (AWS | Azure | GCP)
  Découvrez comment les modifications sont fusionnées et déployées à l'aide d'un modèle de branching qui suit les meilleures pratiques.
• Declarative Automation Bundles (AWS | Azure | GCP)
  Découvrez comment les Asset Bundles sont utilisés pour packager et déployer les ressources Databricks de manière cohérente dans tous les environnements.
• CI/CD pour le déploiement automatisé sur Databricks (AWS | Azure | GCP)
  Découvrez comment implémenter l'intégration et le déploiement continus (CI/CD) avec des scripts de démarrage GitHub Actions (AWS | Azure | GCP)
• Utilisation des Asset Bundles depuis l'interface utilisateur (UI) de l'espace de travail Databricks (AWS | Azure | GCP)
  Découvrez comment créer, modifier et déployer des bundles directement depuis l'espace de travail.
• Dossiers basés sur Git dans Databricks (AWS | Azure | GCP)
  Découvrez comment fonctionne l'intégration de Git dans Databricks et comment le contrôle de version s'intègre dans les workflows d'analyse quotidiens.

Si vous êtes prêt à passer à l'étape suivante avec Databricks AI/BI, vous pouvez choisir l'une des options suivantes :

• Édition gratuite et essai : Familiarisez-vous avec l'outil en vous inscrivant à notre édition gratuite ou à notre essai.
• Documentation : Plongez plus en détail dans le sujet grâce à notre documentation.
• Page web : Visitez notre page web pour en savoir plus.
• Démos : Regardez nos vidéos de démonstration, suivez des visites guidées du produit et accédez à des tutoriels pratiques pour voir AI/BI en action.
• Formation : Commencez dès aujourd'hui grâce aux formations gratuites sur les produits proposées par la Databricks Academy.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original