[VS2005/SSIS] Version control management

[LuCarD]

Ik ben nu bezig met een VS2005/SSIS project, maar ik heb een aantal problemen met betrekking tot versie beheer.

Als er een wijziging in een gedeelte van de SSIS, dan kan andere ontwikkelaar niet met dezelfde file werken. Tevens als er een wijziging in test zit, dan kan er geen nieuwe ontwikkeling gedaan worden totdat de wijziging goed gekeurd is en in de productie opgeving is gebracht.

Tot op heden heb ik de volgdende methodes toegepast om problemen te voorkomen:
- De SSIS project heb ik opgedeeld in zo klein mogelijke logische pakketen. En ik heb dus nu ongeveer rond de 30 verschillende SSIS Packages.
- Veel overleg met de 2 andere ontwikkelaars, over wie in welke Package werkt. En met locks werken via SVN.

Maar het is toch niet echt heel handig. We hebben nog steeds problemen. Doordat het soms lang duurt voordat we resultaat terug krijgen van de testers. Waardoor we niet verder kunnen ontwikkelen in packages die worden gelockt door de change.

Ik ben dus op zoek naar een betere manier om te gaan met wijzigingen binnen development-test en productie.
Verder zoek ik een mogelijkheid om een FileCompare / FileMerge voor een VS2005/SSIS ( de code is niet leesbaar, en we zitten vast aan de visual editor! ) Dus textcompare/merge is niet mogelijk.

[Kalentum]

Ik kan alleen maar voor subversion spreken maar een veel gebruikte methode is om een basis-tak te hebben waar de developers in werken. Op het moment dat je een release doet voor de testomgeving maak je een nieuwe ontwikkeltak 'test'. Code wijzigingen die uit het testen komen doe je in die tak en OOK in de basisbranche, indien nodig (die merge je dan terug). Hierdoor kan je gewoon doorwerken aan je basis-tak.

[MMUilwijk]

LuCarD schreef op vrijdag 14 december 2007 @ 11:54:
Verder zoek ik een mogelijkheid om een FileCompare / FileMerge voor een VS2005/SSIS ( de code is niet leesbaar, en we zitten vast aan de visual editor! ) Dus textcompare/merge is niet mogelijk.

Ik volg je even niet. De dtsx files (waarin de daadwerkelijke SSIS componenten inclusief properties zitten) zijn toch gewoon XML files? Waarom kun je die niet comparen c.q. mergen met een redelijk XML tooltje?

[LuCarD]

MMUilwijk schreef op donderdag 20 december 2007 @ 21:41:
[...]


Ik volg je even niet. De dtsx files (waarin de daadwerkelijke SSIS componenten inclusief properties zitten) zijn toch gewoon XML files? Waarom kun je die niet comparen c.q. mergen met een redelijk XML tooltje?

Er is een BIDSHelper, die kan redelijk laten zien wat er veranderd is. Maar mergen is niet mogelijk.

Voorbeeld van hoe de XML zonder bidshelper eruit ziet staat op deze site
http://www.codeplex.com/b...0Diff&referringTitle=Home

[Verwijderd]

De dtsx zijn wel in XML, maar daar is dan ook alles meegezegd. Zodra je iets wijzigt en opslaat, dan wijzigt de hele XML structuur en kan je niet meer mergen (of 'diff-en'). Het is XML, maar gedraagt zich als een binair bestand (binaire xml ).

In subversion, moet je dtsx bestanden dan ook locken en ontlocken, net zoals je met binaire bestanden zou doen. Hierdoor worden in praktijk packages, zoveel mogelijk opgedeeld in (te) kleine packages, om in ieder geval met meeder ontwikkelaars er aan te kunnen werken.

Dit is echt een misser van Microsoft. Hopelijk hebben ze dit in SQL 2008 opgelost, maar daar heb ik me nog niet in verdiept.