Gérer les branches dans les espaces de travail Microsoft Fabric
L’objectif de cet article est de présenter aux développeurs de Fabric différentes options pour créer des processus d’intégration continue et livraison continue (CI/CD) dans Fabric basés sur des scénarios client courants. Cet article se concentre davantage sur la partie intégration continue (CI) du processus CI/CD. Pour découvrir une discussion sur la partie livraison continue (CD), consultez gérer les pipelines de déploiement.
Cet article décrit quelques options d’intégration distincts, mais de nombreuses organisations utilisent une combinaison d’entre elles.
Prérequis
Pour intégrer Git à votre espace de travail Microsoft Fabric, vous devez configurer les prérequis suivants dans Fabric et Git.
Prérequis Fabric
Pour accéder à la fonctionnalité d’intégration Git, vous avez besoin de l’une des options suivante :
- Une licence Power BI Premium. Une licence Power BI Premium prend uniquement en charge tous les éléments Power BI.
- Une capacité Fabric. Une capacité Fabric est nécessaire pour utiliser tous les éléments Fabric pris en charge. Si vous n’en avez pas encore, inscrivez-vous à un essai gratuit.
De plus, les commutateurs de client suivants doivent être activés à partir du portail d’administration :
- Les utilisateurs peuvent créer des éléments Fabric
- Les utilisateurs peuvent synchroniser des éléments d’espace de travail avec leurs référentiels Git
- Pour les utilisateurs GitHub uniquement : les utilisateurs peuvent synchroniser des éléments d’espace de travail avec des référentiels GitHub
Ces commutateurs peuvent être activés par l’administrateur client, l’administrateur de capacité ou l’administrateur de l’espace de travail, en fonction des paramètres de votre organisation.
Conditions préalables pour Git
L’intégration Git est actuellement prise en charge pour Azure DevOps et GitHub. Pour utiliser l’intégration Git à votre espace de travail Fabric, vous avez besoin des éléments suivants dans Azure DevOps ou GitHub :
- Un compte Azure actif inscrit auprès du même utilisateur qui utilise l’espace de travail Fabric. Créer un compte gratuit.
- Accès à un référentiel existant.
Processus de développement
L’espace de travail Fabric est un environnement partagé qui accède aux éléments en direct. Toutes les modifications apportées directement dans l’espace de travail remplacent et affectent tous les autres utilisateurs de l’espace de travail. Par conséquent, la meilleure pratique Git pour les développeurs consiste à travailler de manière isolée en dehors des espaces de travail partagés. Il existe deux façons pour un développeur de travailler dans son propre espace de travail protégé.
- Développer à l’aide d’outils clients, tels que Power BI Desktop pour les rapports et les modèles sémantiques, ou VS Code pour les notebooks.
- Développer dans un espace de travail Fabric distinct. Chaque développeur dispose de son propre espace de travail dans lequel il connecte sa propre branche distincte, synchronise le contenu dans cet espace de travail, puis commite dans la branche.
Pour utiliser des branches à l’aide de l’intégration Git, connectez d’abord l’espace de travail partagé de l’équipe de développement à une seule branche partagée. Par exemple, si votre équipe utilise un espace de travail partagé, connectez-le à la branche primaire dans le référentiel de votre équipe et synchronisez l’espace de travail et le référentiel. Si le flux de travail de votre équipe comporte plusieurs branches partagées telles que les branches Dev/Test/Prod, chaque branche peut être connectée à un espace de travail différent.
Ensuite, chaque développeur peut choisir l’environnement isolé dans lequel travailler.
Scénario 1 : développer en utilisant des outils clients
Si les éléments que vous développez sont disponibles dans d’autres outils, vous pouvez travailler sur ces éléments directement dans l’outil client. Tous les éléments ne sont pas disponibles dans chaque outil. Les éléments disponibles uniquement dans Fabric doivent être développés dans Fabric.
Le flux de travail pour les développeurs utilisant un outil client comme Power BI Desktop doit ressembler à ceci :
Clonez le référentiel dans un ordinateur local. (Vous ne devez effectuer cette étape qu’une seule fois.)
Ouvrez le projet dans Power BI Desktop à l’aide de la copie locale du PBIProj.
Apportez des modifications et enregistrez les fichiers mis à jour localement. Commitez dans le référentiel local.
Lorsque vous êtes prêt, envoyez (push) la branche et commitez dans le référentiel distant.
Testez les modifications par rapport à d’autres éléments ou à d’autres données en connectant la nouvelle branche à un espace de travail distinct et en chargeant le modèle sémantique et les rapports à l’aide du bouton Tout mettre à jour dans le volet de contrôle de code source. Effectuez des tests ou des modifications de configuration avant de fusionner dans la branche principale.
Si aucun test n’est requis dans l’espace de travail, le développeur peut fusionner les modifications directement dans la branche principale, sans avoir besoin d’un autre espace de travail.
Une fois les modifications fusionnées, l’espace de travail de l’équipe partagée est invité à accepter le nouveau commit. Les modifications sont mises à jour dans l’espace de travail partagé et tout le monde peut voir les modifications apportées à ces modèles sémantiques et rapports.
Pour obtenir des conseils spécifiques sur l’utilisation du nouveau format de fichier Power BI Desktop dans Git, consultez Format de code source.
Scénario 2 : développer en utilisant un autre espace de travail
Pour un développeur qui travaille sur le web, le flux se présente comme suit :
Sous l’onglet Branches du menu Contrôle de code source, sélectionnez Brancher vers un nouvel espace de travail.
Spécifiez les noms de branche et d’espace de travail. Nouvelle branche créée en fonction de la branche connectée à l’espace de travail actif.
Sélectionner Branchement.
Fabric crée l’espace de travail et la branche. Vous êtes automatiquement redirigé vers le nouvel espace de travail.
L’espace de travail se synchronise avec votre branche de fonctionnalité et devient un environnement isolé dans lequel travailler, comme illustré. Vous pouvez maintenant travailler dans ce nouvel environnement isolé. La synchronisation peut prendre quelques minutes. Consultez les conseils de dépannage pour plus d’informations sur le branchement.
Enregistrez vos modifications et commitez-les dans la branche de fonctionnalité.
Lorsque vous êtes prêt, créez une demande de tirage (PR) dans la branche principale. Les processus de révision et de fusion sont effectués via Azure Repos en fonction de la configuration que votre équipe a définie pour ce référentiel.
Une fois la révision et la fusion terminées, un nouveau commit est créé dans la branche principale. Ce commit invite l’utilisateur à mettre à jour le contenu de l’espace de travail de l’équipe de développement avec les modifications fusionnées.
Pour plus d’informations, consultez les limitations de branchement.
Processus de mise en production
Le processus de mise en production commence une fois que de nouvelles mises à jour terminent un processus de demande de tirage (pull request) et fusionnent dans une branche partagée de l’équipe (comme Main, Dev, etc.). À partir de là, nous allons décrire les différentes options pour créer un processus de mise en production dans Fabric. Vous trouverez les différentes considérations du processus de mise en production dans gérer les pipelines de déploiement.
Passer d’une branche à l’autre
Si votre espace de travail est connecté à une branche Git et que vous souhaitez basculer vers une autre branche, vous pouvez le faire rapidement à partir du volet Contrôle de code source sans vous déconnecter et vous reconnecter.
Lorsque vous changez de branche, l’espace de travail se synchronise avec la nouvelle branche et tous les éléments de l’espace de travail sont remplacés. S’il existe différentes versions du même élément dans chaque branche, l’élément est remplacé. Si un élément se trouve dans l’ancienne branche, mais pas dans la nouvelle branche, il est supprimé.
Pour basculer entre les branches, procédez comme suit :
Sous l’onglet Branches du menu Contrôle de code source, sélectionnez Changer de branche.
Spécifiez la branche à laquelle vous souhaitez vous connecter ou créez une branche. Cette branche doit contenir le même répertoire que la branche actuelle.
Sélectionnez Changer de branche.
Vous ne pouvez pas changer de branche si vous avez des modifications non validée dans l’espace de travail. Sélectionnez Annuler pour revenir en arrière et valider vos modifications avant de changer de branche.
Pour connecter l’espace de travail actuel à une nouvelle branche tout en conservant l’état de l’espace de travail existant, sélectionnez Extraire une nouvelle branche. Découvrez plus d’informations sur l’extraction d’une nouvelle branche sur Résoudre les conflits dans Git.