0

After I have finished my first SharePoint development on my development environment, new issues automatically raised. Mainly on how to transfer my SharePoint application from my development to my production environment. My current concerns are as follow:

  1. After deploying a SharePoint application to my production server, users will start adding contents, libraries , etc, to the live system.
  2. So at a certain point of time, I will need these changes so that any future development inside my development environment should be tested against the latest changes. So how I will be managing the production server changes to be reflected on the development environment.

So from where I can get more details about managing the SharePoint versions on different environments mainly from:-

  1. Development--> to Staging --> to production.
  2. Production--> to staging -->  to development.

BR

Improve this question

1 Answer 1

Reset to default
2

From Development to Staging and Production, always use SharePoint Solution Packages (WSPs) so the SharePoint farm itself takes care of deploying all the artefacts to all the SharePoint servers. Make sure you create WSPs and features to deploy web.config changes as well. Use TFS or any other source control to keep track on all deployments and tie them up to their respective source code versions. If you strictly follow this structure migrating content from production back to development should be a matter of backing up and restoring your applications content database(s) to the desired environment and attaching it back to the respective web application.

Improve this answer
4
  • thanks for the reply,, but what do u mean by "Make sure you create WSPs and features to deploy web.config changes as well". do u mean that I should do all my work such as creating document library, list items, pages using Visual Studio and features, and that I should avoid creating these items using the Central administration ?
    – John John
    Commented Jun 10, 2013 at 15:05
  • 1
    No, I mean use wsp to deploy web.config changes when required. Things like appSettings, connectionStrings and any other changes your custom components may need to operate. SharePoint objects like list/libraries/items etc can sure be created via the UI and that is what you would expect business users to do anyway. Let me know if you still need clarification!
    – Miguel Lima
    Commented Jun 10, 2013 at 15:11
  • Thanks a lot for your reply. Well as this is my first deployment, I am not sure about the amount & type of work I need to do. On my development server I have created a publishing site, containing 5 sub sites. Then I modify the page layout using SP designer. And I have also created a farm solution ad I added it to the sub sites. I have also created a term store and Meta data navigation. But I am not sure if all these changes can be deployed using WSP ? and what work I should re-apply on the production server. Can you advice on this?
    – John John
    Commented Jun 10, 2013 at 15:53
  • Your farm solution if packaged as a wsp file can be deployed to your other environments using PowerShell and Central Admin. A backup of the site collection will cover you for your publishing site and any changes you've made using SP Designer and for your term store you can follow this post from Andrew Connell. I hope that answers all your questions.
    – Miguel Lima
    Commented Jun 13, 2013 at 12:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.