SharePoint Development / Production Environment

Question

One of the biggest problems that I encountered with SharePoint is that it does not bring a pleasant attitude to a typical project environment, which at least contains development and production environments. The problems that I encountered are that the content and lists are so closely related that it makes it difficult to make design changes without freezing the content in the production environment. For example, if I have a list with calculated columns and you want to add some new functions, I will need to freeze the contents on the production server, create a list template (including content) from the production server, restore this list to the development environment, make my changes, and then cancel the list template process. The same is true for pages and everything else in SharePoint. It seems that as soon as the site is deployed, it is best to work directly on the production box, but for obvious reasons this breaks a ton of best practices.

How do some of the other SharePoint developers deal with this limitation?

Answer 1

There are two levels (more?) For SharePoint "development". You have code that is deployed to the server, such as web parts, content types, workflow actions, etc. This works relatively well in terms of deployment and best practices.

Then you have your own example, which is more dependent on the configuration of the site instances. What we did when we had to configure the calculated field in the list of portal site catalogs was to try to configure changes in the development. Then write down the detailed configuration instructions, and the individual with the appropriate permissions uses these instructions to make changes on the integration server (intermediate). Then the same person makes changes to the production.

I'm not sure that your changes are susceptible to this approach, but it is worth considering.

Then we have another site that is highly customizable using the SharePoint designer, and one that we work with.

Answer 2

You can use the Content Deployment Wizards ( http://www.codeplex.com/SPDeploymentWizard ) to quickly transfer things like lists and libraries. You can also take a backup / restore copy of the product, then make changes to it, and then freeze the contents in the early morning hours (I hope nobody cares), import all the changed data from the production into your copy, and then restore the copy over the production . At least the freeze can be delayed and will only be necessary during the export-> import-> restore procedure.

In practice, I just do my production changes manually.

Answer 3

Use FeatureActivation code to deploy changes to list fields. After the code updates the fields, you disable this function and delete it. This allows you to check the results in a QA environment before starting work.