Contrôle de code source, CI/CD et ALM pour l’agent de données Fabric (préversion)

Cet article explique comment gérer les agents de données Fabric à l’aide des pipelines d’intégration et de déploiement Git dans le cadre des fonctionnalités de gestion du cycle de vie des applications (ALM) de Microsoft Fabric. Vous apprenez à connecter un espace de travail à un dépôt Git. Vous allez également apprendre à suivre et à versionner les configurations de l’agent de données. Enfin, vous allez apprendre à promouvoir les mises à jour dans les environnements de développement, de test et de production. Les pipelines d’intégration et de déploiement Git permettent l’intégration continue et le déploiement continu (CI/CD) des modifications de l’agent de données, ce qui permet de tester et de promouvoir automatiquement les mises à jour dans le cadre de votre workflow ALM. Le contrôle de code source pour les agents de données Fabric est actuellement en préversion.

Vous pouvez utiliser deux approches complémentaires pour prendre en charge ALM pour les agents de données Fabric :

• Intégration git : synchronisez un espace de travail entier avec un dépôt Git (Azure DevOps ou GitHub en tant que fournisseur Git) pour activer le contrôle de version, la collaboration par le biais de branches et le suivi de l’historique pour des éléments individuels, y compris les agents de données Fabric.
• Pipelines de déploiement : promouvoir le contenu entre des espaces de travail distincts représentant des phases de développement, de test et de production à l’aide de pipelines intégrés.

Ces fonctionnalités fournissent ensemble une prise en charge ALM de bout en bout pour les agents de données Fabric.

Important

Cette fonctionnalité est en version préliminaire.

Prerequisites

• Une capacité Fabric F2 ou supérieure payante, ou une capacité Power BI Premium P1 ou supérieure avec Microsoft Fabric activé
• Les paramètres du locataire de l'agent de données Fabric sont activés.
• Le traitement intergéographique pour l’IA est activé.
• Le stockage multi-régional pour l’IA est activé.
• Au moins l’un d’entre eux, avec des données : un entrepôt, un lachouse, un ou plusieurs modèles sémantiques Power BI, une base de données KQL ou une ontologie.
• Les modèles sémantiques Power BI via le commutateur de locataire des points de terminaison XMLA sont activés pour les sources de données de modèle sémantique Power BI.

Intégration de Git

L’intégration de Microsoft Fabric Git synchronise un espace de travail Fabric avec un dépôt Git, ce qui vous permet d’utiliser vos processus de développement, outils et bonnes pratiques existants directement dans la plateforme Fabric. Il prend en charge Azure DevOps et GitHub et est disponible au niveau de l’espace de travail. Lorsque vous validez les modifications de Fabric, notamment les mises à jour apportées à la configuration de l’agent de données, ces modifications sont enregistrées en tant que fichiers dans le référentiel Git connecté. Ses principales fonctionnalités sont les suivantes :

• Sauvegarde complète et contrôle de version des éléments de l’espace de travail
• La structure de dossiers dans Git reflète la structure de l’espace de travail
• Les configurations de l’agent de données (sélection de schéma, instructions IA, instructions de source de données, exemples de requêtes) sont stockées dans des fichiers structurés dans des dossiers dédiés
• Possibilité d’afficher les différences, d’examiner l’historique et de revenir aux états antérieurs via l’historique pour différents éléments de l’espace de travail, y compris les agents de données
• Collaboration basée sur les branches (branche de fonctionnalités, branche principale)

Pour plus d’informations sur le processus d’intégration Git, vous pouvez consulter les ressources suivantes.

• Qu’est-ce que l’intégration de Microsoft Fabric Git ?
• Concepts de base de l’intégration Git
• Démarrer avec l’intégration Git

Configurer une connexion au contrôle de code source

Vous pouvez connecter votre espace de travail Fabric à un dépôt Git à partir de la page paramètres de l’espace de travail . Cette connexion vous permet de valider et de synchroniser les modifications directement à partir de Fabric.

1. Consultez Prise en main de l’intégration de Git pour obtenir des étapes détaillées pour vous connecter à un dépôt Git dans Azure DevOps ou GitHub.

2. Après vous être connecté au référentiel Git, vos éléments d’espace de travail, y compris les agents de données Fabric, apparaissent dans le panneau de configuration de code source. Dans la barre d’état située en bas à gauche, vous pouvez voir le nom de la branche connectée, l’heure de la dernière synchronisation et l’ID de validation Git.

3. Le référentiel Git lié affiche une structure de dossiers représentant vos éléments d’espace de travail, y compris les agents de données Fabric et leurs fichiers de configuration. Chaque agent de données est stocké dans son propre dossier, ce qui vous permet de passer en revue les modifications, de suivre l’historique des versions et d’utiliser des flux de travail Git tels que la création de demandes de tirage pour fusionner les mises à jour dans votre branche principale.

4. Lorsque vous apportez des modifications à l’agent de données Fabric dans un espace de travail connecté à Git, les modifications sont détectées et l’état de l’agent de données dans le volet Contrôle de code source change en cas de modifications non validées. Ces modifications peuvent inclure :

   • Modification de la sélection du schéma.
   • Mise à jour des instructions d’IA ou des instructions de source de données.
   • Modification d’exemples de requêtes.
   • Publication de l’agent de données ou mise à jour de sa description de publication.

Toute modification, qu’elle soit fonctionnelle ou descriptive, entraîne l’interruption de la synchronisation de l’agent de données avec le référentiel Git lié. Les éléments de l’espace de travail avec modifications s’affichent sous l’onglet Modifications dans le volet Contrôle de code source. Vous pouvez passer en revue ces modifications, les comparer à la version validée et les confirmer de nouveau dans le référentiel Git pour les synchroniser avec celui-ci.

5. Lorsque des mises à jour sont effectuées directement dans le référentiel Git lié (Azure DevOps ou GitHub), elles peuvent inclure des actions telles que la modification d’instructions IA, la modification d’exemples de requêtes ou la modification des descriptions de publication. Vous pouvez ensuite valider et envoyer (push) ces modifications au référentiel. Une fois les mises à jour envoyées et disponibles dans le référentiel, votre espace de travail Fabric les détecte et affiche une notification mises à jour disponible dans le volet contrôle de code source. Les éléments mis à jour tels que l’agent de données apparaissent sous l’onglet Mises à jour, où vous pouvez les examiner et les accepter. L’acceptation de ces mises à jour applique les modifications de référentiel à vos éléments d’espace de travail, ce qui garantit que l’espace de travail reflète la dernière version validée dans Git.

Structure de dossiers et de fichiers dans le référentiel Git

Dans ce qui suit, vous passez en revue la structure de la façon dont la configuration d’un agent de données est stockée dans un dépôt Git. Comprendre cette structure est importante pour gérer les modifications et suivre les meilleures pratiques.

Structure racine

À la racine, le contenu de l’agent de données est stocké sous le dossier fichiers . Dans les fichiers, vous trouverez un dossier de configuration , qui contient data_agent.json, publish_info.json, le dossier brouillon et le dossier publié.

Dans le dossier de configuration , le publish_info.json contient la description de publication de l’agent de données. Ce fichier peut être mis à jour pour modifier la description qui s’affiche lorsque l’agent de données est publié.

Le dossier brouillon contient les fichiers de configuration correspondant à la version brouillon de l’agent de données et le dossier publié contient les fichiers de configuration de la version publiée de l’agent de données. Le dossier brouillon contient :

• Dossiers de source de données où il existe un dossier pour chaque source de données utilisée par l’agent de données.
  • Sources de données de type lakehouse ou entrepôt : les noms de dossiers commencent par lakehouse-tables- ou warehouse-tables-, suivis du nom du lakehouse ou de l’entrepôt.
  • Sources de données de modèle sémantique : les noms de dossiers commencent semantic-model-par , suivis du nom du modèle sémantique.
  • Sources de données de base de données KQL : les noms de dossiers commencent kusto-par , suivis du nom de la base de données KQL.
  • Sources de données ontologie : les noms de dossiers commencent ontology-par , suivis du nom de l’ontologie.

• stage_config.json qui contient aiInstructions, qui fait référence aux instructions de l’agent.

Chaque dossier de source de données contient datasource.json et fewshots.json. Toutefois, si la source de données est un modèle sémantique, elle ne prend pas en charge les exemples de requêtes. Par conséquent, son dossier contient uniquement datasource.json.

Le datasource.json définit la configuration de cette source de données, notamment :

• dataSourceInstructions, qui représente les instructions fournies pour cette source de données.

• displayName, qui affiche le nom de la source de données.

• elements, qui fait référence à la carte de schéma et inclut une liste complète de tables et de colonnes à partir de la source de données.

  • Chaque table a une is_selected propriété. Si true, la table est incluse et si false, cela signifie que la table n’est pas sélectionnée et ne sera pas utilisée par l’agent de données.
  • Les entrées de colonne affichent également is_selected, mais la sélection des colonnes n’est pas prise en charge actuellement. Si une table est sélectionnée, toutes ses colonnes sont incluses indépendamment de la valeur de colonne is_selected . Si une table n'est pas sélectionnée (is_selected : false au niveau de la table), aucune des colonnes n'est prise en compte, même si is_selected est réglé sur true au niveau de la colonne.

• Conventions de type :

  • Si le type est une source de données, il s’agit simplement du type de source de données (par exemple : "type": "lakehouse_tables").
  • Si le type est une table, il se termine par .table (par exemple : "type": "lakehouse_tables.table").
  • Si le type est une colonne, il se termine par .column (par exemple : "type": "lakehouse_tables.column").

Le fewshots.json stocke des exemples de requêtes pour la source de données. Chaque entrée inclut :

• id en tant qu’identificateur unique pour l’exemple de requête.
• question, qui fait référence à la question du langage naturel.
• query affiche le texte de la requête, qui peut être SQL ou KQL en fonction du type de source de données.

Le dossier publié reflète la structure du dossier brouillon, mais représente la version publiée de l’agent de données. Il est recommandé de ne pas modifier les fichiers directement dans le dossier publié. Les modifications doivent être apportées dans le dossier brouillon. Une fois l’agent de données publié, ces modifications sont répercutées dans le dossier publié. Cela garantit que la version publiée est toujours générée à partir d’un état brouillon contrôlé.

Chaînes de déploiement pour les agents de données

Les pipelines de déploiement fournissent un moyen contrôlé de déplacer des agents de données entre des espaces de travail mappés à différentes étapes de cycle de vie. Par exemple:

1. Développez un nouvel agent de données ou mettez à jour un agent de données existant dans l’espace de travail de développement.
2. Promouvoir les modifications apportées à l’espace de travail de test pour validation.
3. Promouvoir les modifications testées dans l’espace de travail de production où elle est disponible pour les utilisateurs finaux.

Avant de déployer, vous devez affecter un espace de travail à chaque étape du pipeline de déploiement : développement, test et production. Si vous n’affectez pas d’espace de travail à la phase de test ou de production, les espaces de travail sont automatiquement créés. Les espaces de travail créés automatiquement sont nommés après l’espace de travail de développement, avec [test] ou [prod] ajouté.

Pour déployer des modifications :

• Dans le pipeline, accédez à la phase à partir de laquelle vous souhaitez déployer (par exemple, le développement).
• Sélectionnez les éléments de l’espace de travail que vous souhaitez déployer.
• Sélectionnez Déployer pour les promouvoir à l’étape suivante.

Vous pouvez passer en revue un plan de déploiement avant d’appliquer des modifications, ce qui garantit que seules les mises à jour prévues sont promues. Pour plus d’informations, consultez Prise en main des pipelines de déploiement.

Note

Les principaux de service sont pris en charge dans l’agent de données Fabric uniquement dans le cadre de scénarios ALM. Cette prise en charge est limitée à l’activation des opérations ALM (telles que les pipelines d’intégration et de déploiement Git) et ne s’étend pas à d’autres fonctionnalités de l’agent de données Fabric. Si vous devez interagir avec un agent de données en dehors des flux de travail ALM, le principal de service n’est pas pris en charge.

Publier un agent de données Fabric pour les pipelines de déploiement

La publication d’un agent de données Fabric le rend disponible pour une utilisation sur tous les différents canaux de consommation, notamment Copilot pour Power BI, Microsoft Copilot Studio et Azure AI Foundry Services. Pour évaluer et consommer l’agent de données sur ces canaux, l’agent de données doit être publié ; Les agents de données non publiés ne sont pas accessibles pour la consommation même s’ils se trouvent dans un espace de travail de production. Pour suivre les meilleures pratiques en accord avec le pipeline de déploiement, notez que :

• La publication à partir d’un espace de travail de développement doit être limitée aux utilisateurs autorisés uniquement qui travaillent sur le développement de l’agent de données et souhaitent évaluer ses performances sur différents canaux de consommation. L’accès à cet espace de travail doit être limité afin que les agents de données non terminés ou expérimentaux ne soient pas exposés à des audiences plus larges.
• Les utilisateurs finaux doivent accéder aux agents de données publiés à partir de l’espace de travail de production uniquement, en s’assurant qu’ils interagissent avec des versions stables et approuvées de l’agent de données.

Cette approche prend en charge à la fois l’exigence fonctionnelle d’activation de la consommation et de l’évaluation des performances, et garantit un contrôle d’accès approprié en conservant les environnements de développement et de production distincts.

Meilleures pratiques

• Utilisez une branche dédiée pour le travail de développement sur les agents de données et fusionnez-la vers la branche principale après la révision du code.
• Conservez les ressources associées (sources de données, agents de données, notebooks, pipelines) dans le même espace de travail pour faciliter la promotion.
• Tester les modifications apportées à l’agent de données dans l’espace de travail de test avant de promouvoir en production.
• Utilisez des messages de validation descriptifs pour faciliter la compréhension de l’historique.
• N’apportez pas directement de modifications au dossier publié dans le référentiel Git.

Limitations et considérations

• Seuls les espaces de travail connectés à un référentiel Git peuvent utiliser des fonctionnalités ALM basées sur Git.
• Les principaux de service sont pris en charge dans l’agent de données Fabric uniquement dans le cadre de scénarios ALM. Si vous devez interagir avec un agent de données en dehors des flux de travail ALM, le principal de service n’est pas pris en charge.
• Les pipelines de déploiement nécessitent que les espaces de travail source et cible se trouvent dans le même tenant.
• Un grand nombre de validations fréquentes peuvent avoir un impact sur la taille et les performances du référentiel.

Contenu connexe

• Démarrer avec l’intégration Git
• Concepts de base de l’intégration Git
• Qu’est-ce que la gestion du cycle de vie dans Microsoft Fabric ?