March 6, 2017 at 12:13 pm
I am admittedly a newbie to Source Code Control (TFS in our case). We started the process by storing all SSIS jobs beneath a single Team Project. While we have a small team and haven't come across any issues yet, I thought of one today. Let's just say we have 2 SSIS solutions, SSIS1.sln and SSIS2.sln, each within their own folder within the Team Project.
Let's say developer1 is working on SSIS1.sln, and completes their work, while developer2 is only partially done with their work on SSIS2.sln, but has been checking their work into the dev branch. When developer1 merges the dev branch into main, they will pull in developer2's partially completed efforts into the main branch.
How do others organize their SSIS source code within TFS to circumvent this type of issue? Since we're sharing the repository with the WPF/ASP development staff, we were trying not to inflate the number of Team Project by a large amount by creating a separate project per SSIS job, which is why we broke off into a more tiered folder arrangement.
Thanks for your insight,
--=Chuck
March 6, 2017 at 12:37 pm
We don't have a single dev branch. We have a branch for every ticket in our system. Only the owner of the ticket should be modifying the branch corresponding to the ticket, so you won't be checking in other people's partial work.
Drew
J. Drew Allen
Business Intelligence Analyst
Philadelphia, PA
March 6, 2017 at 1:03 pm
This may be the wrong use of terminology, since I'm new to this, but using your approach it's like you're treating everything like a hotfix, correct? Only using that term, because in our current development standards, development happens in a singular dev branch unless a hotfix branch is created to make a more immediate change, which is moved the main branch before the dev branch changes are complete. Then we merge main into dev to pickup the hotfix.
--=cf
March 6, 2017 at 1:11 pm
I simplified things. There is a main branch and an integration branch off of that main branch. (This is still a simplified version.) The bug tickets are branches off of the integration branch. When we have tested our changes, we merge them to the integration branch. Once the integration branch has been thoroughly tested, it is then merged with the main branch.
From what I can tell, our integration branch would roughly correspond to your shared dev branch.
Drew
J. Drew Allen
Business Intelligence Analyst
Philadelphia, PA
March 6, 2017 at 1:25 pm
I like the idea of the intervening integration branch. In all honesty, I didn't know until now that a branch could be more than 1 node deep (main->integration->bug ticket).
I may be back after I look at a suggestion one of our .NET developer brought up. He was thinking that each developer could create a shelveset off of the dev branch, which as I'm typing this, sounds akin to your setup. So, I'll look into the differences between a shelveset and an actual branch, and examine the merits/drawbacks of one over the other.
Thanks for the help. It was considerable.
--=Chuck
March 6, 2017 at 2:04 pm
drew.allen - Monday, March 6, 2017 12:37 PMWe don't have a single dev branch. We have a branch for every ticket in our system. Only the owner of the ticket should be modifying the branch corresponding to the ticket, so you won't be checking in other people's partial work.Drew
Out of interest, are you doing that in TFS? Sounds more like a Git way of working.
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
March 6, 2017 at 2:57 pm
Phil Parkin - Monday, March 6, 2017 2:04 PMdrew.allen - Monday, March 6, 2017 12:37 PMWe don't have a single dev branch. We have a branch for every ticket in our system. Only the owner of the ticket should be modifying the branch corresponding to the ticket, so you won't be checking in other people's partial work.Drew
Out of interest, are you doing that in TFS? Sounds more like a Git way of working.
We're using TortioseSVN.
J. Drew Allen
Business Intelligence Analyst
Philadelphia, PA
March 6, 2017 at 3:19 pm
Phil,
If you don't mind, what is the TFS-way?
--=Chuck
March 6, 2017 at 3:30 pm
chuck.forbes - Monday, March 6, 2017 3:19 PMPhil,
If you don't mind, what is the TFS-way?
--=Chuck
In my experience, TFS is nothing like as flexible as Git when it comes to branching and merging. When I've used TFS, this has meant adopting a fairly static and well-defined branching structure. Something like
QA --> Pre-Production --> Production
Nothing gets checked into QA which 'breaks the build' (or if it does, it has to be fixed PDQ by the person who broke it). Half-baked development work does not get checked in – only complete chunks of work. Before doing a check-in to QA, it's a developer's responsibility to 'Get Latest' and resolve any conflicts before checking in.
I have run out of time right now. Please post back with any more questions and I'll get back to you when I can.
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
March 13, 2017 at 1:34 am
This was removed by the editor as SPAM
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply