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?
Add a comment
|
2 Answers
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.
answered Sep 30, 2013 at 19:52
-
For your second point: Is this solution file already existant somewhere or do I have to create it? And then how is it deployed to the other site? edit: Are you referring to features?– FenoecCommented Sep 30, 2013 at 20:55
-
1You can create solutions in Visual Studio 2010/2012, Check out msdn.microsoft.com/en-us/library/ee330921.aspx for loads of info. The solution file outputs as a .wsp file, that is added to SP in 2 ways: for farm solutions, you use PowerShell to add it, for sandbox solutions, you upload it to the site collection. Commented Oct 1, 2013 at 11:48
-
Is it possible to deploy a partial solution to a site? Like if I make a change to a web part I only want to deploy that web part again. I tried removing the other web parts from my feature and when I deployed that it broke and none of my web parts were displayed on the page. The concern I have is if 2 people are working on 2 different pieces of the project at once that deploying the entire solution will cause issues of overwriting changes that were already deployed by somebody else (unless they always get the latest version of the entire project before deploying).– FenoecCommented Oct 1, 2013 at 16:14
-
but my in my site all artifacts works proper except the page layout what can be the reason?– user32550Commented Aug 20, 2014 at 5:35
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!)
