Je suis actuellement un seul développeur BI sur une dataware et un cube d'entreprise. J'utilise SQL Server 2008, SSAS et SSIS comme solution à outils de base. J'utilise des enchères Visual Studio + TFS pour mon IDE et mon contrôle source. Je suis sur le point de prendre plusieurs projets avec un fournisseur offshore et je suis inquiet de gérer le changement. Ma principale préoccupation est la fusion et les changements entre moi et l'équipe offshore. La fusion et la gestion des modifications apportées à SQL & XML pour une seule personne est suffisamment mauvaise, mais avec plusieurs développeurs, cela ressemble à un cauchemar. Toute réflexion sur la meilleure façon de structurer le développement sachant que parfois il n'ya aucun moyen d'éviter de multiples personnes de modifier le même fichier?
4 Réponses :
http://code.google.com/p/support/wiki/dvcsanalyse
Peut-être une meilleure étiquette est-elle DVCS? https://stackoverflow.com/questions/tagged/dvcs
TFS est le seul outil autorisé à mon employeur. La passer à un système de contrôle source complètement différent n'est pas une option.
Désolé après avoir répercuté votre message original, je comprends que votre question soit davantage sur la fusion et la réduction de la manière de contrôler les packages et les cubes. J'ai édité ma réponse, j'espère que vous le trouverez utile.
Tant que les deux équipes utilisent des offres et TFS, cela ne devrait pas être un problème.
En supposant que votre code TSQL soit vérifié pour contrôler la source dans un seul fichier par objet, la fusion de code TSQL est simple car il est basé sur le texte. J'ai trouvé les projets de base de données VSTS Aide avec cela.
fusionner les fichiers source basés sur XML de SSIS et les MSA peuvent être encombrants comme vous l'indiquez ci-dessous. Pour atténuer une partie de la douleur, je constate que garder chaque paquet limité à une seule unité de données ou logique de travail permet de réduire la conflit de développeurs sur des packages. J'appelle ensuite ces paquets d'un ou plusieurs packages principaux. J'essaie également d'externaliser toutes mes requêtes de source TSQL à l'aide de Sprates, de la vue ou des UDF, de sorte que la nécessité de modifier le package soit réduite. L'utilisation de fichiers de configuration et de variables contribue également à une moindre mesure.
Les cubes MSSAS sont un peu plus difficiles. Ma meilleure suggestion est de regarder dans un outil de différenciation XML tiers. J'ai été en mesure de fusionner avec succès de petites modifications à utiliser les outils de texte standard, mais il peut s'agir d'une tâche décourageante.
Si vous pensez que la fusion des packages SSIS n'est pas différente de tout autre type de code source, vous n'avez pas utilisé les SSIS ou les grands documents XML dans un environnement d'équipe.
Les fichiers SSIS, SSAS et SSRS ne sont pas fusionnés. Ils sont stockés dans un fichier XML modifié radicalement - même avec des changements mineurs (tels que la modification d'une propriété) - il devient donc vraiment impossible de fusionner.
arrêtez donc de penser à un développement parallèle sur un fichier. Vous devez penser comment vous pouvez réaliser que les personnes n'ont pas besoin de faire du développement parallèle sur un fichier. Donc, commencez à désactiver la commande multiple d'un fichier. Vous voudrez peut-être même envisager d'activer la possibilité d'obtenir la dernière version sur une caisse.
Commencez ensuite à penser à ce que vous pouvez réaliser que les gens peuvent travailler indépendants. Ceci est plus dans la façon dont vous structurez le travail et les fichiers:
J'ai donné des commentaires à l'équipe de produits de l'imCompatible des offres de fusionner. C'est un problème connu, mais il sera difficile de s'attaquer. Ils ne savent pas quand il sera possible de réellement faire un développement parallèle sur ces fichiers. Jusqu'à ce qui reste loin du développement parallèle.
Comme Ewald Hofman mentionné, SSAS et SSIS ne sont pas fusionnés.
Dans un environnement, j'ai travaillé résolu le problème comme suit:
Construisez une application C # qui construisez vos dimensions et vos cubes via le AMO API (Je sais, c'est un travail difficile au début, mais il vaut la peine - pensez à ce que vous gagnez - regardez les avantages ci-dessous)
Ajoutez la base de données sur scène et l'application C # à votre référentiel (TFS / GIT, etc.)