February 16, 2018 at 4:49 am
Hi all
we're having a bit of a tidy-up of our TFS solution/projects and wanting to improve where things sit.
We've currently got all the solutions in one folder and some package-level connections which point to our DEV and PROD servers.
What I want to do is to have the following folder structure:-
DEV - anything we're currently working on (or is completed and deployed - for backup purposes)
PROD - only the solutions that are actively in use on our production server
ARCHIVE - anything that's no longer in use but might be useful in future
I've done some digging but I can't see a way to copy the solutions from the DEV folder to the PROD folder ready for deployment on our PROD server.
Two questions:-
1) Am I going about this the right way?
2) How do I copy the solutions between folders while leaving the original alone?
Any help on this would be gratefully received.
February 16, 2018 at 5:06 am
richardmgreen1 - Friday, February 16, 2018 4:49 AMHi allwe're having a bit of a tidy-up of our TFS solution/projects and wanting to improve where things sit.
We've currently got all the solutions in one folder and some package-level connections which point to our DEV and PROD servers.
What I want to do is to have the following folder structure:-
DEV - anything we're currently working on (or is completed and deployed - for backup purposes)
PROD - only the solutions that are actively in use on our production server
ARCHIVE - anything that's no longer in use but might be useful in futureI've done some digging but I can't see a way to copy the solutions from the DEV folder to the PROD folder ready for deployment on our PROD server.
Two questions:-
1) Am I going about this the right way?
2) How do I copy the solutions between folders while leaving the original alone?Any help on this would be gratefully received.
Do you use branching in TFS? Moving items from DEV to PROD (where did QA go, by the way? :)) via the TFS branching mechanism is the generally accepted way of progressing changes through environments.
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
February 16, 2018 at 5:14 am
We haven't been using branching at all. I'm not sure how it works.
Do you have a link to some fairly idiot-proof info?
As for QA, it's done on the DEV box (don't ask(!)).
We do the initial build, testing and QA on one box and then push to production for general usage.
February 16, 2018 at 5:33 am
richardmgreen1 - Friday, February 16, 2018 5:14 AMWe haven't been using branching at all. I'm not sure how it works.
Do you have a link to some fairly idiot-proof info?As for QA, it's done on the DEV box (don't ask(!)).
We do the initial build, testing and QA on one box and then push to production for general usage.
Not really, but had a quick hunt around ...
Have a read here for an introduction to branching and why you would use it. It's not about TFS, but the concepts are the same, regardless of your specific VCS. Once you understand why you would use branching, you can investigate how it is done in TFS. Once you start, you won't go back.
If you are just in the early stages of using TFS, I'd also recommend that you check out git. I've used both (and a couple of others) and git is slicker and faster in most respects.
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
February 16, 2018 at 5:54 am
So, from a quick read on that page, our main "trunk" would be what's on the production server, with branches for whatever is being worked on (fixes, new stuff, etc).
Have I read that right?
If I have, we'd need to create the trunk almost empty and then immediately do a branch.
February 16, 2018 at 6:06 am
richardmgreen1 - Friday, February 16, 2018 5:54 AMSo, from a quick read on that page, our main "trunk" would be what's on the production server, with branches for whatever is being worked on (fixes, new stuff, etc).Have I read that right?
If I have, we'd need to create the trunk almost empty and then immediately do a branch.
Your existing branch (where everything is currently checked in) is Trunk/Master.
You can branch to DEV from that, but you probably don't want to do that (having a folder called PROD in your DEV branch will immediately confuse everyone involved).
It's been a couple of years since I used TFS, so I don't want to give you bad advice on this, but here's a general idea:
1) Your main/master branch should be Prod. It will contain the contents of your Prod folder (and not the DEV folder)
2) Branch this to a Dev branch. This will create an exact copy of Prod in the Dev branch.
3) Apply the differences from Dev (ie, the stuff which is being worked on now, but has not yet made it into prod) on the Dev branch.
4) When you are ready to move the changes into the Prod branch, perform a merge from Dev to Prod.
(TFS will track the differences between Dev and Prod for you.)
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
February 16, 2018 at 6:16 am
That sounds quite straight-forward.
I suppose the only other way to do it would be to do the following:-
Create solution on DEV and work on them
When we're ready for deploying, use the "Add Items" option in TFS to port the solutions across (after creating the solutions if necessary) onto PROD and deploy.
Looks like we've got some research to do and a fairly sizeable discussion as to the best way forward.
February 16, 2018 at 6:24 am
richardmgreen1 - Friday, February 16, 2018 6:16 AMThat sounds quite straight-forward.I suppose the only other way to do it would be to do the following:-
Create solution on DEV and work on them
When we're ready for deploying, use the "Add Items" option in TFS to port the solutions across (after creating the solutions if necessary) onto PROD and deploy.Looks like we've got some research to do and a fairly sizeable discussion as to the best way forward.
I don't think that your suggestion makes good use of all the functionality TFS offers you.
Perhaps you could set up small pilot project to get your hands dirty with branching and merging? Is there a solution which only two or three of you are working on?
After doing this for a while, you'll be in a much better position to decide on the way forward.
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
February 16, 2018 at 6:29 am
There's only 3 of us in the team and we're usually working on different bits and pieces.
It's only when it comes to deployment it becomes a bit of an issue.
I'll have a dig around in branching and see what I can find out.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply