Using Team Foundation in Multiple Environments?
-
We have the standard Production, QA and Dev environments on our web site. We use them for the obvious purposes. What we want is to use Team Foundation Server to do source control. I just started here and I have been tasked with figuring out how to do this correctly. Currently, we have three different projects in the source control, which represent each of the environments. I do not think this is correct. I have read a lot of literature about this and nothing seems to make sense. We do not publish the entire application to the web servers, instead we put up individual pages when they are changed. We need to support the following standard things: 1. Ability to know what is in the three environments at any given time 2. Ability to roll back to previous (tested and correct) versions of the web site in any environment 3. Ability to know what changes are tested and verified in QA and Dev, so we can promote code 4. We need to ensure that changes are not made in production until they are tested in the QA environment. 5. We need to sync the source control with the versions on the servers, so that developers will be able to pull a copy of the 'server version' from source control directly. Right now, to do that, you have to pull the source control version and then update the files from the web server... which is stupid because they should always be the same. Standard stuff... I think? I have read so many articles about this it's making my head spin. Certainly this is not hard enough to justify 500-page documents??? http://www.codeplex.com/TFSGuide/Release/ProjectReleases.aspx?ReleaseId=6280[^] What is the simple way to do this? My proposal is to eliminate two of the current project repositories, and only have one, which we would make a branch from, do development on the branch, and then merge the development back into the main branch when it's done, apply a label to the result after the merge, and promote that label to production when it has been tested in QA... but I think I'm missing something with that. I want this to be simple, or nobody will do it. We want to avoid making changes directly in production. We should be able to eliminate all temptation to do that. People requesting changes will just have to deal with the new policy of reviewing the changes in QA before they are put to p
-
We have the standard Production, QA and Dev environments on our web site. We use them for the obvious purposes. What we want is to use Team Foundation Server to do source control. I just started here and I have been tasked with figuring out how to do this correctly. Currently, we have three different projects in the source control, which represent each of the environments. I do not think this is correct. I have read a lot of literature about this and nothing seems to make sense. We do not publish the entire application to the web servers, instead we put up individual pages when they are changed. We need to support the following standard things: 1. Ability to know what is in the three environments at any given time 2. Ability to roll back to previous (tested and correct) versions of the web site in any environment 3. Ability to know what changes are tested and verified in QA and Dev, so we can promote code 4. We need to ensure that changes are not made in production until they are tested in the QA environment. 5. We need to sync the source control with the versions on the servers, so that developers will be able to pull a copy of the 'server version' from source control directly. Right now, to do that, you have to pull the source control version and then update the files from the web server... which is stupid because they should always be the same. Standard stuff... I think? I have read so many articles about this it's making my head spin. Certainly this is not hard enough to justify 500-page documents??? http://www.codeplex.com/TFSGuide/Release/ProjectReleases.aspx?ReleaseId=6280[^] What is the simple way to do this? My proposal is to eliminate two of the current project repositories, and only have one, which we would make a branch from, do development on the branch, and then merge the development back into the main branch when it's done, apply a label to the result after the merge, and promote that label to production when it has been tested in QA... but I think I'm missing something with that. I want this to be simple, or nobody will do it. We want to avoid making changes directly in production. We should be able to eliminate all temptation to do that. People requesting changes will just have to deal with the new policy of reviewing the changes in QA before they are put to p
I think you are getting it a bit backwards. Generally you do the bulk of your development on the trunk. If you have a smaller project then you can just take a release, version it and push that thru QA and release. On a larger project you might choose to branch off a release, and only apply "serious" fixes to the current release branch (still doing QA on the fixes), merging that back into the trunk. Having multiple source control systems is just going to lead to disaster.
Mark Churchill Director Dunn & Churchill Free Download:
Diamond Binding: The simple, powerful, reliable, and effective data layer toolkit for Visual Studio. -
We have the standard Production, QA and Dev environments on our web site. We use them for the obvious purposes. What we want is to use Team Foundation Server to do source control. I just started here and I have been tasked with figuring out how to do this correctly. Currently, we have three different projects in the source control, which represent each of the environments. I do not think this is correct. I have read a lot of literature about this and nothing seems to make sense. We do not publish the entire application to the web servers, instead we put up individual pages when they are changed. We need to support the following standard things: 1. Ability to know what is in the three environments at any given time 2. Ability to roll back to previous (tested and correct) versions of the web site in any environment 3. Ability to know what changes are tested and verified in QA and Dev, so we can promote code 4. We need to ensure that changes are not made in production until they are tested in the QA environment. 5. We need to sync the source control with the versions on the servers, so that developers will be able to pull a copy of the 'server version' from source control directly. Right now, to do that, you have to pull the source control version and then update the files from the web server... which is stupid because they should always be the same. Standard stuff... I think? I have read so many articles about this it's making my head spin. Certainly this is not hard enough to justify 500-page documents??? http://www.codeplex.com/TFSGuide/Release/ProjectReleases.aspx?ReleaseId=6280[^] What is the simple way to do this? My proposal is to eliminate two of the current project repositories, and only have one, which we would make a branch from, do development on the branch, and then merge the development back into the main branch when it's done, apply a label to the result after the merge, and promote that label to production when it has been tested in QA... but I think I'm missing something with that. I want this to be simple, or nobody will do it. We want to avoid making changes directly in production. We should be able to eliminate all temptation to do that. People requesting changes will just have to deal with the new policy of reviewing the changes in QA before they are put to p
Jasmine2501 wrote:
Certainly this is not hard enough to justify 500-page documents???
Well I pretty sure that document covers a lot more than just Source Control. However, in any problem solving scenario many solutions provide only partial coverage of the problem space or even introduce a new set of problems, hence the potential complexity of any given problem space.
Jasmine2501 wrote:
What is the simple way to do this? My proposal is to eliminate two of the current project repositories, and only have one,
I don't know if it is "the" simple way but I agree with Mark that it is a common approach.
led mike
-
I think you are getting it a bit backwards. Generally you do the bulk of your development on the trunk. If you have a smaller project then you can just take a release, version it and push that thru QA and release. On a larger project you might choose to branch off a release, and only apply "serious" fixes to the current release branch (still doing QA on the fixes), merging that back into the trunk. Having multiple source control systems is just going to lead to disaster.
Mark Churchill Director Dunn & Churchill Free Download:
Diamond Binding: The simple, powerful, reliable, and effective data layer toolkit for Visual Studio.Mark Churchill wrote:
Having multiple source control systems is just going to lead to disaster.
This I agree with. I was surprised to see it like that. I think you are correct that we should only have one project, with not many branches or anything. We don't have multiple versions of the project... it is all one big thing, with constant updating going on - a typical web site for a large company. The result is a fairly nice site... but from the code... you wouldn't think so. It is a heterogeneous environment, with SQL Server and Oracle, several 3rd party applications, and a mixture of Cold Fusion and ASP.Net stuff... Here is the result: http://www.awwa.org/[^] This organization does a lot of good for the world, so I'm not afraid to do a little promotion. There isn't much there for the average Joe, but it's interesting to me anyway...
"Quality Software since 1983!"
http://www.smoothjazzy.com/ - see the "Programming" section for freeware tools and articles.