Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

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

share|improve this question
add comment

1 Answer 1

up vote 2 down vote accepted

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.

share|improve this answer
    
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 G Jun 10 '13 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 Jun 10 '13 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 G Jun 10 '13 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 Jun 13 '13 at 12:02
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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