UAT refresh best practices

Question

The scenario is as follows: SP2010 production farm and UAT farm will have the same setup.

As work items are pulled to production, and users add content and SP Designer changes to production, and at the same time work items get rejected in UAT, the gap between UAT and prod increases.

How often do you refresh UAT? Do you bring only the content DB's back? How do you manage configuration changes?

EDIT: After thinking a little bit more about this, I think I'm mixing the purpose of UAT and QA. i guess the question here is really how to balance the purpose of both environments when they are merged into one.

EDIT 2: I think I'm seeing things in a different perspective now. Here's the solution I'm thinking of now: With nightly builds (Anyone else knows of valid alternatives to TFS?) We spawn a machine with the latest version of the code for continuous UAT.

As the work items leave UAT they go to QA, a copy on demand of the latest Prod backup.

Even if I don't have builds for now, I should still aim for immediate deploy of completed WI to this one farm, and make sure the PS Scripts are ready to bring it quickly back to life.

Thoughts?

Answer 1

Here's our setup, if that can help you with ideas on getting your setup like you want it:

Build Setup

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.

Test Setup

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.

Answer 2

UAT should be considered disposable in terms of content. It's there for testing, not for live content authoring. You should not need to 'migrate' content from UAT to Live, but you can have a regular backsync of content from Live to UAT, such that recent functional changes can be tested with 'recent' content.

The publishing approval features of SharePoint should avoid the need to have a 'content staging server' which I see floating around. A staging server should be there solely to test functionality, not author content.