A big question I get asked as a consultant “So how do we keep our SharePoint Development, Test, UAT and Production environments in sync, especially our SharePont Production and UAT as we really need to verify everything is working.” This question again can be answered by good SharePoint governance, striking again! A few basic things I try to follow:
SharePoint does give you a host of tools to help you out. One answer lies in Content Deployment paths. Which are useful at publishing new features and promoting up. It’s important to remember though that Content Deployment paths are one way however. They don’t sync backwards and forwards. They also don’t do anything about what lies outside of the Site Collecton (Features to be installed at the Web App Level, Server changes, GAC Deployed assemblies, amongst many others). Though it’s a help. You need to closely manage content deployment and have a sharp eye for setting things up. Typically this is how a corporate SharePoint environment runs:
1) Various SharePoint developers, designers, authors, etc. setup their work on their own development servers. Have fun and play around on them. Once a new feature they’ve built is now declared “code complete, needs testing” usually by passing all its unit tests, the person in charge of the new feature creates a content deployment job, and deploys to test.
2) Test is a “convergence” environment, where all developers gather from their development SharePoint environments and see how their features work with each other, and get an idea of how production is going to handle the new feature. At this level, all unit tests must pass now to promote to test now and other tests such as load testing and full integration testing are done here.
3) So, the testing team likes this new feature now and they give it a green light to go further. The next step from here is to double-check that production and UAT are in sync. Often it’s a good practice to run a deployment path down from production to UAT before uploading the new code via content deployment path from test. The idea here is to get the UAT environment looking exactly like the “to be” state of production, and continue testing there.
4) Once satisfied, off to production we go. Of course you test on production as well, but if all goes well this should be a formality.
This works well at the SharePoint Site Collection level and below, but for features that exist at the farm, web application or whole server levels we need to think about how to manage these procedures. Typically I always follow the procedure of 1) Develop, 2) Test, 3) Refresh UAT from Production 4) Test to UAT, 5) UAT from production in all I do. The trick is to standardize the deployment. To do this you have a few options:
1) SharePoint .WSP files are portable from environment to environment and can be deployed in a similar process as a content deployment path. They can also deploy more things such as Farm and Web Application scoped features, Assemblies, etc.
2) If you need to install a third-party tool (SharePoint or otherwise), consider using an automated installer if at all possible. At a minimum make sure the installation on each environment is throughly documented.
3) Manual Server Change on the SharePont servers? Again documented…especially on production. What is helpful at the production level is a “peer system” one person doing, and another person taking notes of what was done or attempted, then printing up the report.
Another good friend in ensuring consistency is the Virtual Machine snapshot feature. I like to follow a best practice of taking a snapshot before any server change in production. I’ve heard of some brave folk who go so far as refreshing UAT machines by copying in the production machines, renaming the machines and changing the IP Addresses to UAT names and addresses. The one trick here is SQL Server too, you would have to use aliases to make sure your server name isn’t pointing back to production databases when you copy back to UAT. The first thing you would have to do after copying the machines over is changing the production aliases to UAT aliases pointing to the newly copied over UAT Server.
Anyways there are lots to think about in SharePoint deployment. You likely could just write-up a whole book on the topic. Good luck!
