I just started a new job where they only have a development (DEV) server and a production (PROD) server. Every place I have worked before has always had a third server in-between DEV and PROD. Some places called the in-between server Stage, and some called it Test. I'm not sure if a Stage and Test server are one in the same, or if they are actually two different types of servers. But they were always used for the same thing - to give the customer a place to review the site before it went live on the PROD server. For the purpose of this post I will call it a TEST server. I asked my new boss about the possibility of creating a TEST server. He asked me to justify the need for a TEST server. Now, I can't debate myself out of a wet paper bag, so my justifications were extremely weak. I was wondering if anyone had a list of reason to support the need for a TEST server, or knew of a web site or book that I can reference to provide a reason why a TEST server is needed. If the concept of a TEST server is outdated, and no longer needed, then please let me know as well. It wouldn't be the first time I was doing something that didn't need to be done anymore. Thanks.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Stage/Test Server
- Thread starter ibwebn65
- Start date
There IS a difference between a test and and a staging server.
The last place I worked at had DEV-TEST-UAT/STAGING-PROD setup.
Normally there are 2 groups managing the web content. Developers and marketing staff. Marketing staff will manage images, daily/weekly content refreshes, minor javascript, and non-breaking .aspx changes.
This work is normally done on a STAGING server, which is [sometimes] available outside the firewall. These would be normally "test.mysite.com" set ups. This area is also sometimes call UAT or User Acceptance Test servers. They can be used for soft launches of new site content. The marketing team was responsible for migrating the data back to the "lower" environments for us.
A TEST server is normally for use internally for the IT group to manage it's process prior to Go-Live. Depending on how complex your integrations and team, the machine you have currently [as DEV] may be what some shops call a TEST machine.
The critical thing is that you have a separate place from your local machine that you can test the WHOLE deployment process prior to prod.
If you can't argue for another machine, you have 2 options:
Modifying your machine to have a copy of the database, making your machine the DEV location, and the other the TEST.
Create database(s) on the DEV setup with different names and use them for DEV work. I suggest this so that when you rename them [correctly] for test they don't need to be tweaked again for PROD.
HTH,
Lodlaiden
A lack of experience doesn't prevent you from doing a good job.
The last place I worked at had DEV-TEST-UAT/STAGING-PROD setup.
Normally there are 2 groups managing the web content. Developers and marketing staff. Marketing staff will manage images, daily/weekly content refreshes, minor javascript, and non-breaking .aspx changes.
This work is normally done on a STAGING server, which is [sometimes] available outside the firewall. These would be normally "test.mysite.com" set ups. This area is also sometimes call UAT or User Acceptance Test servers. They can be used for soft launches of new site content. The marketing team was responsible for migrating the data back to the "lower" environments for us.
A TEST server is normally for use internally for the IT group to manage it's process prior to Go-Live. Depending on how complex your integrations and team, the machine you have currently [as DEV] may be what some shops call a TEST machine.
The critical thing is that you have a separate place from your local machine that you can test the WHOLE deployment process prior to prod.
If you can't argue for another machine, you have 2 options:
Modifying your machine to have a copy of the database, making your machine the DEV location, and the other the TEST.
Create database(s) on the DEV setup with different names and use them for DEV work. I suggest this so that when you rename them [correctly] for test they don't need to be tweaked again for PROD.
HTH,
Lodlaiden
A lack of experience doesn't prevent you from doing a good job.
- Status
Similar threads
- Locked
- Question
- Locked
- Question