SharePoint 2013 Dev/Test/Production environment - Moving content

Question

I am new to SharePoint and am working on a project with a separate SharePoint site on a different farm for each stage of development (Development, Testing, and Production). Is there a good way to move all content between SharePoint sites including master page, layout pages, css, custom web parts, etc. without having to move files individually and laying out web parts on each page again manually?

Answer 1

Welcome to SharePoint! Get ready for the ride of your life!

Moving stuff from environment to environment will depending on your stuff:

• Content, like list items and documents, can't be easily moved. They can be moved with 3rd party solutions, or custom code. You can do it with a C# solution or even using PowerShell.
• Stuff like lists, libraries, master pages, CSS, etc. should be packaged in a solution file, either sand box or farm solution. This solution file can contain all of the assets you require, and then it can be deployed into a new environment, which then provisions all the stuff you need (it could also load up test/sample data if needed)
• Another nice solution, if you're working with a brand new site, is to back it up and restore it into another environment. That helps get the bulk of the stuff copied over, and then you can use one of the above methods for continuing updates.

Answer 2

In the SharePoint world, everything that you listed is known as artifacts, not content. Content would be articles, blog postings, discussions and any other end-user generated data. There are two types of artifacts - solution artifacts that are created in Visual Studio and Authored artifacts that are created using Designer or the SharePoint UI.

In general, content moves backward through environments (from Prod to QA to Dev) while artifacts move forward (Dev to QA to Prod). There are a few mechanisms in place to make this happen though their utility will vary depending on how you have created your content and artifacts

• For empty or small sites you can use Site Templates to move this information back and forth but bear in mind that if your customizations have included hard-coding paths or GUIDs into web parts then this will fail as the path will differ as will all GUIDs associated with the lists.
• In 2013, SharePoint Design Manager also offers the option to package solutions for easier distribution. I have not worked with this personally so cannot speak to the upsides/downsides of it.
• A one-shot trick that I've seen done is to create the bulk of the customizations in a QA environment prior to the site going into production, then simply move the content database from QA to Production for release. This can only be done once and then only at launch as all new content is generated in production and any subsequent replacement of the content database would lose all production changes. This is not recommended because once the site does go live, you are now left to figure out how to move changes there.
• If this is the staging/authoring site for a publishing site, you can also configure Publishing Jobs to push content and authored artifacts from the staging environment to production
• Lastly, Visual Studio offers the cleanest approach to moving customizations across environments but it also is the most technical and requires an investment of time to get right. It also requires that a server administrator deploy the solution for you. As I understand it, this is also not really a viable option when working with the SharePoint Online / Office 365 as it does not allow custom code (though I would be happy to be corrected on this point!)