Microsoft SharePoint 2013 Deployment Strategy

/in

“How to keep our Microsoft SharePoint Development, Test, UAT and Production environments in sync, especially our Microsoft SharePoint Production and UAT as we really need to verify everything is working?” This question can be answered by good SharePoint Governance and a few basic things stated as under:

There are the host of tools to help people out in this regard. One of the options can be 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 backward and forwards. They also don’t do anything about what lies outside of the Site Collection (features to be installed at the Web Application Level, Server changes etc.). You will need to closely manage content deployment and have a sharp eye for setting things up.

Ideally, this is how a corporate SharePoint environment is managed:

  • SharePoint developers, designers, authors, etc. set up their work on their own development servers to perform the assigned work on the same.
  • Once a new feature which they have built is ready for quality control after passing all its unit tests, the person in charge of the feature creates a content deployment job and then deploys the same to the test environment.
  • A test is a kind of “merging” environment where all developers gather from their development SharePoint environments and see how their features work once integrated 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 environment now and other tests such as load testing and full integration testing are done here.
  • If the quality control team gives it a go ahead, there is a need to double-check whether production and UAT are in sync.
  • 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 a test environment. The idea here is to get the UAT environment looking precisely like of production and continue testing the feature on the same.
  • Once “QC OK” on UAT, the feature is then deployed on the production environment. Again, one test cycle is performed on production environment by the Quality Control team (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 you will need to think about below procedure of,

  • Develop the code and perform unit tests
  • Quality Control performing rounds of Testing.
  • Refresh the pilot environment from the Production environment
  • Quality Control performing Test on pilot or UAT environment
  • Deployment of code from UAT environment to production environment.

The approach is to standardize the deployment procedure. In order to do the needful, people can have a few options:

  • SharePoint “.WSP” files are portable from an 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.
  • In case of installation of a third-party tool (Microsoft SharePoint or otherwise), people will need to consider the use of an automated installer (if possible). At a minimum, people will have to make sure the installation on each environment is thoroughly documented (must!!)
  • In the case of Manual Server Change on the SharePoint servers, again it needs to be documented, especially in the production environment. 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 option to ensure consistency is the Virtual Machine snapshot (it’s a point in time version of a virtual machine) feature. As a best practice, people can take a snapshot before any server change in production.