…for it is only when a man goes out into the world with the thought that there are heroisms all round him, and with the desire all alive in his heart to follow any which may come within sight of him, that he breaks away as I did from the life he knows, and ventures forth into the wonderful mystic twilight land where lie the great adventures and the great rewards.
Sir Arthur Conan Doyle has it right at the end of the first chapter of “The Lost World.” Business Intelligence is currently the land of “great adventures” and certainly of “great rewards.” Unfortunately, it’s also a Lost World when it comes to source control. Sure, you can put your SSAS, SSIS, and SSRS projects and solutions into Team Foundation Server, and it will even check in and check out code for you. However, when it comes to really taking advantage of the power of TFS, the Business Intelligencer is left looking stupid in a world wherein the only code that exists is MVC.
I’m attempting to (re)organize our BI efforts into a coherent project (rather than spread out across several) since, although the projects themselves don’t necessarily need to interact, the work items most assuredly do. This will allow me to create a single backlog, manage the variations through areas, and track the various work across three separate domains via the appropriate iterations so burn-down charts work right.
So, in perusing the ALM Rangers copious guidance to TFS structuring, branching, and merging, I’ve decided that although the “real developer” world is well represented, we poor Business Intelligencers are left outside with the raging monsters.
Ok, that may be enough with the imagery. Speaking of imagery, here’s where we were headed initially with our branching/merging strategy:
We quickly realized that wouldn’t readily meet our needs for a number of reasons, namely, you couldn’t see proper branching strategies at work and having multiple Analysis projects, for instance, just got ugly. So, we changed it to look like this:
And that works much better. Of course, I look a little silly now because it still follows the same patterns as normal development practices :-). One of the other things we’re struggling with, though, is how (or whether) to incorporate a SQL Server Database Project into the mix. Because we use the database for all three areas, Analysis, ETL, and Reporting, it becomes a little odd to have a branching strategy for all three mixed with a single database project (unless I’m missing something?).