Je me demande si quelqu'un a des conseils sur la fusion des fichiers DTSX de la SSIS. Voici les problèmes que je vois qui rendent la fusion difficile:
Si quelqu'un de Microsoft écoute, beaucoup de ces problèmes sont résolus en faisant des paquets plusieurs fichiers plutôt qu'un fichier. Un DTSX pourrait être un XML décrivant le flux, un XML décrivant la mise en page, certains fichiers source .CS et certaines DLL. Mais ce n'est pas comme ça. me fait me demander pourquoi quelqu'un utilise DTSX.
La seule solution que j'ai vue en ligne est de vous assurer que le fichier DTSX est verrouillé lors de la modification de sorte qu'un seul utilisateur aura des modifications. Cela fonctionne bien lorsque vous parlez d'une succursale que si vous travaillez avec plusieurs copies du DTSX dans diverses branches (ou que Dieu interdit, DVCS ), alors il n'y a pas de moyen réalisable de les verrouiller tout quand vous faites un changement. En outre, cela ne résoudrait pas vraiment le problème à moins que vous ne puissiez également vous assurer que personne d'autre ne l'a changé avant de pouvoir la fusionner partout.
5 Réponses :
Je recommanderais d'éviter la fustion de fichiers DTSX à tout prix - ça va être un monde de douleur! La façon dont je développe généralement des projets SSIS consiste à diviser chaque œuvre distincte en un fichier paquet / DTSX distinct, puis les appelez à partir d'un package maître. Cela signifie que différentes personnes de l'équipe peuvent travailler sur différents forfaits sans se chevaucher sur les autres. Cela fonctionne très bien dans un système contrôlé par la source. Un autre avantage est que chaque composant peut être exécuté indépendamment ou testé.
Nous faisons des fractionnements en petits forfaits, mais la plupart de nos forfaits font des choses très spécifiques qui ne se prêtent pas bien à les diviser en morceaux plus petits. Même avec cela, cela ne fonctionne que pour garder les gens de marcher sur les orteils dans la même branche. Disons que nous avons un package pour importer un format de fichier spécial. Nous trouvons un bogue et la réparez dans ce DTSX dans la version 1.0 de notre logiciel. Mais dans les parties de la branche 2.0 d'Import.tsx ont été modifiées pour obtenir une meilleure performance ou quelque chose du genre. Ces deux changements doivent être fusionnés ou nous aurons à nouveau ce bogue à nouveau lorsque 2.0 est libéré.
Seule façon dont nous nous fusionnerons au travail consiste à ouvrir les deux paquets, à tout copier à partir d'un package, collez-la dans l'autre, puis compilez chaque tâche de script s'ils ont des conflits.
Travailler avec des paquets plus petits est souhaitable, car ils répondent simplement plus vite.
Copier le contenu d'un DTSX (appelons la source informatique) à une autre (appelons-la cible) et la sauvegarde ne fusionne pas. Cela ne fait que jeter tout ce qui a changé dans la cible. Si la source et la cible ont changé, vous souhaitez que le résultat final soit une combinaison des changements des deux.
Je pensais à la fusion comme ça, fusionner le fichier A et B - pas dans une source de contrôle source: | Ne pas tenir compte de mon commentaire (s)
Si vous avez besoin de véritables capacités de fusion, vous devrez coder manuellement les paquets. En raison de tout le câblage (identifiants de lignage, etc.) et des spécificités de concepteur dans le XML, il n'est pas moyen de fusionner des modifications entre les fichiers sans casser les flux de données ni la disposition.
C'est ce que je pense aussi. Que vous ne pouvez pas les fusionner. Je marquerais cela comme la réponse, mais cela vient vraiment de confirmer le problème. Je ne sais pas s'il y a est une réponse
Utilisation de l'add-in Visual Studio gratuit Aids Helper peut aider avec votre dilemme à deux manières possibles.
BIML : BIML est une langue de balisage de l'intelligence commerciale ( BIML Référence ). Vous pouvez utiliser des fichiers .biml pour générer vos packages SSIS. Les fichiers BIML doivent mieux fonctionner avec des opérations de fusion en raison de leur structure plus rigide. Bien que je n'ai aucune expérience de la fusionne encore, j'utilise des fichiers BIML pour créer mes packages SSIS plus rapidement que le SSIS UI permet. Il a été très utile avec des flux de données similaires et changeant simplement les attributs uniques.
Smart Diff : Aids Helper a également une fonctionnalité Smart Diff intégrée à Aidez à comparer les différences dans vos packages SSIS. Il ne vous aidera pas à se fusionner automatiquement, mais il éliminera les informations de mise en page et commandera le XML avant de montrer les différences. Cela vous montrera des différences fonctionnelles réelles entre deux packages SSIS. Ensuite, vous pouvez utiliser ces informations pour fusionner manuellement des changements. Pour votre exemple de votre commentaire sur la réponse de Revelator, vous utiliseriez Smart DIFF pour comparer la version 1.0 de votre SSIS à votre version fixe dans la branche 1.0, vous verriez simplement les modifications nécessaires pour appliquer manuellement sur votre branche 2.0. < / p>
Je ne fais plus vraiment SSIS Stuff. Mais cela semble être une réponse décente. Ce truc de Biml semble qu'il serait plus facile de différer (aussi facile que tout fichier XML peut être).
Regardez les transformateurs BIML. BIML (Langue Business Intelligence Markup) est un moyen beaucoup plus facile de modifier et de contrôler vos packages SSIS. Juste bas charger l'aide des offres et consulter cet article.
http://bimlscript.com/walkthrough/Détails/68
Les transformateurs vous permettent également d'appliquer le même changement à un ensemble de packages SSIS non seulement manuellement à la fois.
acclamations
Actuellement une fonctionnalité uniquement disponible dans la brume.