Comment faire du controle de version avec Azure Analysis Services

Question

Je cherche des avis sur un méthode de controle de version pour plusieurs modèles sémantiques Azure Analysis Services.

Je suis dans une équipe qui travaille sur des modèles Azure Analysis Services.

Actuellement, on se partage les modèles avec OneDrive et des stockages réseau spécifiques.

Bien que ces 2 solutions fonctionnent à peu près, ce n'est pas un fonctionnement idéal.

Je me dis du coup qu'il serait intéressant de mettre en place un control de version avec git.

Mon approche est de mettre le fichier bim et le smproj sur une repo git, et de travailler en collab avec ça.

Cependant, j'ai une question :
Est ce que les fichiers "bim" et "smproj" suffisent ?

Lors du développement, nous utilisons des instances locales de Analysis Services lancées par SSDT.

Ce qui veut dire que nous avons un dossier "bin/Data" qui contient toutes les données du modèle sémantique.

Que ce passera t il si "personne A" modifie la structure d'une table, puis "personne B" pull les changements ?

Techniquement, les fichiers "bin/Data" de "personne B" ne correspondent plus au modèle.

Est ce que ça crée un plantage, ou est ce que ça requiert juste une mise à jour des données dans SSDT ?

Ou est ce que cette méthode de contrôle de version est totalement inadaptée ?

Merci d'avance pour vos réponses

Answer 1

Hi D2d3d4d5,

J’utilise un traducteur anglais, veuillez excuser mes éventuelles fautes grammaticales.

Il semble que vous essayez de mettre en place un contrôle de version pour vos projets Azure Analysis Services en utilisant Git :

1. Utilisation des fichiers .bim et .smproj : Les fichiers que vous mentionnez (.bim et .smproj) sont essentiels pour définir le schéma de votre modèle et la structure du projet. Toutefois, ils ne contiennent ni les données réelles ni les configurations de traitement associées.
2. Le dossier bin/Data : Comme vous avez indiqué que votre équipe utilise des instances locales d’Analysis Services, le dossier bin/Data contient les fichiers de données traités pour votre modèle sémantique. Lorsqu’une personne modifie la structure d’une table et qu’une autre récupère ces modifications, cela peut entraîner des incohérences dans les fichiers de données.

Si la « personne A » modifie la structure des tables et que la « personne B » récupère ces modifications sans mettre à jour son instance locale :

• Intégrité des données : Les fichiers de données locaux de la « personne B » ne seront plus alignés avec les nouvelles modifications du modèle.
• Erreurs : Cette situation peut générer des erreurs lorsque la « personne B » tente d’utiliser ou de traiter le modèle, selon l’étendue des modifications.

Suggested workflow:

• Après avoir récupéré les changements depuis Git, les utilisateurs doivent retraiter les modèles dans SSDT pour s’assurer que la couche de données correspond bien au schéma mis à jour.
• Il est également conseillé de communiquer régulièrement entre membres de l’équipe à propos des modifications importantes du schéma, afin de faciliter une intégration plus fluide.

Recomended approach:

• Envisagez d’améliorer votre stratégie de contrôle de version en créant des scripts d’automatisation, par exemple des commandes pour retraiter les modèles après la récupération des mises à jour.
• Définissez un protocole clair pour les modifications de schéma, comme des étapes de pré-validation ou des réunions de synchronisation.

Pour fournir une réponse plus adaptée, voici quelques questions :

1. À quelle fréquence des modifications structurelles sont-elles effectuées dans vos projets d’équipe ?
2. Utilisez-vous une stratégie de branches Git spécifique et comment gérez-vous les fusions ?
3. Les membres de l’équipe rencontrent-ils souvent des conflits lors de la récupération des mises à jour depuis le dépôt partagé ?