Here's our setup, if that can help you with ideas on getting your setup like you want it:
We use TFS for builds with the following setup:
- Nightly build for DevTest
- Manual triggered build for SystemTest. Depends on DevTest
- Manual triggered build for UAT. Depends on SystemTest
- Manual triggered build for Production. Depends on UAT
Depends here means: Builds code from the dependant build with a certain status ("ready for deployment")
Using the build dependencies makes sure we don't get new/untested code into test/prod systems by accident because someone checked in stuff in source control.
For testing environments we have the following:
- DevTest - scratch and rebuild all every night
- DevTest - upgrade every night
DevTest servers are single-box systems for the developers to verify that their code is properly deployed and does what is expected on a server that is not their own. Deployment runs automatically using timerjobs and deployment scripts.
SystemTest - First real user-testing environment. Has all servers that prod has, but less redundancy, we use 1 server pr. role (we have WFE, BI, APP, Crawl, Query, DB). SystemTest is used by the project test team to verify our test-cases from TFS.
It is deployed by running our deployment scripts manually at end of each sprint (2 weeks) using output from SystemTest build.
When we start proper testing (i.e. not developer "does it work" testing, but run through all steps in the defined testcases) we want to test the entire sprint's testcases.
UAT - Full replica of prod. Deployed manually by running deployment scripts using output from UAT build. Done once a month, as we have monthly release cycles. Devteam has no access to these servers, for two purposes: Making sure someone else can install it (in our case, the hosting partner), and making sure dev-guys don't "just fix something" on the servers :). This is installed when all testcases from SystemTest is verified. Everything that is installed here should be production ready. The test team runs all testcases again (2 sprints this time) together with customer in this environment, and gets a sign-off if things are ok. Otherwise it's back to bugfix.
When everything is OK and customer has signed off, it is ready for production install.
We do not copy content from production to our test-rigs.
There are several reasons for this:
- Confidentiality. We do not want production data on test servers, as it is easier for people (devteam, testers etc) to get wider access to this data.
- Data amounts. We can't fit multiples of hundreds of GB on our testracks. It's simply too expensive.
- We make self-carrying test-cases. We do not test content. We test functionality, and if the functionality needs some form of data to successfully be completed, we make steps in those testcases to create the data also.
- What users does with their content and with SP Designer on the production farm is not our problem. Our focus is to make sure the stuff we develop work. Everything else is a support issue :)
End note on your Continuous UAT: We tried this, and it simply did not work for us. It created a lot of noise on a daily basis between the dev team and the test team. We found it better to use the sprints and have devs work in peace for 2 weeks and then do a handover to our testing guys.
That ended up as a long post, but I hope I helped you with some ideas for your setup :) Feel free to ask if you have questions.