Suivi des versions avec Git : méthode industrielle

• Projet Power BI (PBIP) : le rapport et le modèle sont enregistrés en fichiers texte (TMDL pour le modèle, PBIR pour le rapport), lisibles et comparables par Git. Un fichier PBIX, binaire, ne se prête pas au suivi des versions. Source
• Dépôt Git local : sur le poste du développeur, il enregistre l'historique des validations.
• Dépôt distant : Azure DevOps (Azure Repos) ou GitHub, référence partagée de l'équipe.
• Intégration Git de l'espace de travail : un espace de travail Fabric est relié à une branche et à un dossier du dépôt ; il se synchronise dans les deux sens. Source
• Pipelines de déploiement : promotion du contenu de l'espace de développement vers le test puis la production. Source

[Capture d’écran à insérer] Schéma d'ensemble : poste du développeur (Power BI Desktop + VS Code) relié à un dépôt Azure DevOps ou GitHub, lui-même relié à l'espace de travail « Dev », puis flèches vers les espaces « Test » et « Prod » via le pipeline de déploiement.

1. Dans Power BI Desktop, Fichier > Enregistrer sous > type Projet Power BI (*.pbip).
2. Choisir un dossier dédié, qui deviendra le dossier du dépôt Git.
3. Vérifier dans Fichier > Options et paramètres > Options > Fonctionnalités en préversion que le stockage du modèle sémantique au format TMDL et du rapport au format PBIR est activé (formats plus lisibles et mieux fusionnables que model.bim et report.json).

Ventes/
├── Ventes.Report/            # définition du rapport (PBIR)
├── Ventes.SemanticModel/     # définition du modèle (dossier definition en TMDL)
├── .gitignore
└── Ventes.pbip

**/.pbi/localSettings.json
**/.pbi/cache.abf

• cache.abf contient les données importées : elles ne doivent pas aller dans Git (taille, confidentialité). Sans ce fichier, Power BI Desktop ouvre le modèle sans données ; il suffit d'actualiser.
• localSettings.json contient des réglages propres à l'utilisateur et au poste.

[Capture d’écran à insérer] Boîte de dialogue « Enregistrer sous » de Power BI Desktop avec le type « Projet Power BI (*.pbip) » sélectionné, puis l'explorateur Windows montrant les dossiers .Report, .SemanticModel et le fichier .gitignore.

1. Fichier > Ouvrir le dossier : choisir le dossier du projet PBIP.
2. Volet Contrôle de code source > Initialiser le dépôt.
3. Saisir un message (par exemple Version initiale du rapport Ventes) puis Valider (Commit).
4. Publier la branche : VS Code propose de créer le dépôt distant sur GitHub ; pour Azure DevOps, créer d'abord le dépôt dans Repos > Files, puis Clone > Clone in VS Code. Source

[Capture d’écran à insérer] VS Code, volet Contrôle de code source ouvert sur un projet PBIP : liste des fichiers modifiés, zone de message de validation et bouton « Valider ».

cd C:\Projets\Ventes
git init
git add .
git commit -m "Version initiale du rapport Ventes"
git remote add origin https://dev.azure.com/<organisation>/<projet>/_git/<depot>
git push -u origin main

[Capture d’écran à insérer] VS Code en vue de comparaison côte à côte d'un fichier .tmdl : ancienne expression DAX d'une mesure en rouge à gauche, nouvelle en vert à droite.

• Espace de travail sur une capacité Fabric (F) ou Power BI Premium (P), ou Premium par utilisateur.
• Paramètres du locataire activés par l'administrateur : Les utilisateurs peuvent synchroniser les éléments de l'espace de travail avec leurs dépôts Git (et avec les dépôts GitHub pour GitHub).
• Rôle Administrateur de l'espace de travail pour connecter ou déconnecter.
• Côté Git : compte Azure DevOps lié au même utilisateur Microsoft Entra, ou compte GitHub avec un jeton d'accès personnel (lecture et écriture sur Contents).

1. Ouvrir l'espace de travail > Paramètres de l'espace de travail > Intégration Git.
2. Choisir le fournisseur : Azure DevOps ou GitHub, puis se connecter (ou Ajouter un compte).
3. Renseigner l'organisation, le projet, le dépôt, la branche (ou + Nouvelle branche) et le dossier du dépôt.
4. Cliquer sur Connecter et synchroniser.

[Capture d’écran à insérer] Paramètres de l'espace de travail, onglet Intégration Git : fournisseur Azure DevOps sélectionné, listes déroulantes Organisation, Projet, Dépôt, Branche, Dossier, et bouton « Connecter et synchroniser ».

[Capture d’écran à insérer] Espace de travail connecté à Git : colonne « Statut Git » des éléments (Synchronisé, Non validé) et volet Contrôle de code source ouvert sur l'onglet Modifications avec deux éléments cochés.

• Un espace de travail est connecté à une seule branche à la fois.
• Seules les définitions sont synchronisées : les données, les identifiants de connexion et les paramètres d'actualisation ne vont pas dans Git.
• Les scripts de la vue TMDL enregistrés dans le modèle publié ne sont pas embarqués par la synchronisation.
• Les fichiers PBIX publiés sont convertis : dans le dépôt, chaque rapport et chaque modèle apparaissent comme des dossiers au format projet.
• Éléments pris en charge, limites et formats : Source

• Avec Power BI Desktop (outil client) : créer une branche dans VS Code (feature/mesures-marge), modifier le PBIP, valider, pousser, puis ouvrir une demande de tirage vers main. Aucun espace de travail n'est nécessaire pour développer.
• Avec un espace de travail personnel : dans le volet Contrôle de code source, Brancher vers un autre espace de travail crée une branche et un espace de travail dédiés ; on y modifie, on valide, puis on ouvre la demande de tirage.

1. Créer une branche depuis main pour une évolution précise.
2. Faire des modifications petites et fréquentes, une validation par évolution cohérente, avec un message explicite.
3. Mettre régulièrement sa branche à jour depuis main pour régler les conflits soi-même.
4. Ouvrir une demande de tirage (pull request) vers main dans Azure DevOps ou GitHub.
5. Le référent technique relit les différences et approuve la fusion.
6. Dans l'espace de travail d'équipe connecté à main : Mettre à jour pour récupérer la version fusionnée.

[Capture d’écran à insérer] Demande de tirage dans Azure DevOps (ou GitHub) : titre, branche source feature/... vers main, onglet Fichiers montrant la différence sur un fichier .tmdl, bouton « Approuver ».

• Branches : main (référence publiée), feature/<objet>, fix/<objet>.
• Messages de validation : un verbe et l'objet, par exemple Ajoute la mesure Marge % ou Corrige le filtre de la page Synthèse.
• Une validation regroupe les modifications qui doivent être déployées ensemble.
• Éviter les gros fichiers statiques (images lourdes) dans le rapport.

• Modifications non validées : Annuler dans le volet Contrôle de code source.
• Modifications déjà validées : dans le dépôt, git revert <commit> crée une validation qui inverse la précédente ; l'espace de travail affiche alors une mise à jour à appliquer.
• Les données n'étant pas dans Git, actualiser le modèle après un retour en arrière.

[Capture d’écran à insérer] Pipeline de déploiement avec trois étapes (Développement, Test, Production), l'étape Développement portant l'icône Git, et le bouton « Déployer » entre deux étapes.

1. Enregistrer le fichier du fil rouge en PBIP, ouvrir le dossier dans VS Code, initialiser le dépôt et valider la version initiale.
2. Ajouter une mesure dans Power BI Desktop, enregistrer, observer la différence dans VS Code, valider.
3. Créer une branche feature/page-synthese, modifier une page du rapport, valider, revenir sur main et rouvrir le PBIP pour constater que la page n'a pas changé.
4. Fusionner la branche dans main.
5. Si une capacité Fabric (essai gratuit possible) est disponible : connecter un espace de travail à la branche main, synchroniser, modifier un visuel dans le service, Valider, puis récupérer la modification dans VS Code avec git pull.
6. Annuler la dernière validation avec git revert et Mettre à jour l'espace de travail.

• Tutoriel de bout en bout : gestion du cycle de vie avec Git et pipelines de déploiement. Source
• Concepts et bonnes pratiques CI/CD dans Fabric. Source
• Planification de l'implémentation : développer du contenu et gérer les modifications. Source
• Page parente : Mode développeur (Projet Power BI).