Sharepoint 2007 maintenance and staging

Question

I am trying to draft up a comprehensive document to assist the maintenance group for a new Sharepoint 2007 Intranet.

What I have problems deciding is what the right tool is to migrate various different elements to the customer-approval and production environment. We expect in the future to have to deal with new lists, new custom types/list templates, modified pages, new pages, and so on.

In other words, while I think adding a whole subsite is relatively straightforward, incremental changes to existing areas don't seem very easy to me. Especially because the production site has various lists which are updated by customers (bullettin boards, and so on).

So far the best answer seems to be http://www.codeplex.com/SPDeploymentWizard but I have a few residual problems with it:

1) It's beta, and it is not an Official Microsoft Product. So our customer may not be very confident 2) It needs to be installed on all the servers where you want to deliver your changes, and works through a GUI component. This, again, would be something the customer won't be very happy with (their stuff is managed by a third party, just think of EDS or similar companies).

Has anyone used it with confidence in production related scenarios? Do you have different alternatives to suggest?

TIA,

Paolo.

Answer 1

The danger with the content deployment wizard is not actually that it may not work, but more that you may try to migrate objects that are better released as a sharepoint solution with a specific feature.

Specifically, New lists should be released with as a list template defined in a feature. New custom fields must be released with a solution.

A good rule of thumb is that content (i.e. text on pages and documents) can be migrated. Structure (new list types, fields) needs to be released as a solution.

Modified and new pages can be created manually on the site and published when ready. If they absolutely must be released in bulk then the wizard will help.

I have used STSDev also from codeplex in order to create the required solution packages. Remember that even though these tools are not "Official Microsoft Products" they are often heavily used by Microsoft Professionals themselves and would be official tools if the release criteria for "officialdom" were not such a long process.

Check the authors of any tool, most of them will have a blog and that will get you a good idea of the experience and relationship to Microsoft the author may have.

I have not used the SPDeploymentWizard, but from the codeplex site

Content is exported using the Content Migration API (PRIME) as a .cmp file (Content Migration Package) which can be copied to other servers for import. Unlike the out-of-the-box tools, the Wizard allows granular selection of content via a treeview.

That means the tool is a gui wrapper for an "Official Microsoft process", making it easier to select the content you wish to place into a migration package.

The subject of your question is not an easy task in practice and the tools and techniques for doing this are improving and changing, so keep tabs on the blogs and codeplex for advice.

UPDATE

The migration tool should be fine for only the documents and pages you need for each release.

For lists I have create temporary templates that contain all the items, but this is pretty much still a manual release process. So try it with the content migration tool, because you are not making structural changes to the site, it will be possible to delete the list if it does not do things correctly.

The real issue is just to make sure the the content type id and content field id guids are the same from server to server, but with any customisation release by solution/feature packages, there should be no difference.

UPDATE 2

For individual pages, we created a powershell script that would, given a url, a list of files and an action either download the pages from the server to a local drive or upload them. It is pretty easy using the object model to create the pages, custom attributes are a bit trickier, but checking in and publishing the pages was not much of a major.

Answer 2

Thanks Nat for your answer.

I didn't mention this in my original request (my bad) but yes, we have a solution including C# webparts and "structural" definitions like List Templates, as per MS practices.

So the idea of creating templates first, install them as features and instantiate specific lists from a template is already in place.

What I am trying to wrestle with is what the best approach is for:

1) Adding a new page to the test and production farms. (Please understand that development is done by my company on our servers and then must be moved to the testing and finally production sites in the customer's intranet). 2) Modifying a page and then move it to test & prod. 3) Adding a new list instance to test & prod (after having deployed the solution with the list template in it). 4) See 3, but specifically the list has been initialized and already contains items.

From what I have seen so far, "standard" tools seem to work at the subsite level or at the folder level, so if you need to make a bunch of minor changes to different pages across 4-5 subsites you are forced to make the changes "in-place", and by hand, which I think is a wasteful, non-repeatable and error-prone process.