Promoting MOSS '07 Sites From Dev To Production

Question

Hello,

So, maybe I'm a bit old-school, but when we created websites in the past, we'd develop the site on a development server, then publish or promote the pages and files to the production server. This has always seemed to be a good way to go so that users didn't see messed up pages or (God forbid) a downed server because one of us screwed up.

But it doesn't seem that Microsoft had this idea in mind when they created SharePoint...at least, I haven't been able to find a way to do this in the infrastructure as it's defined.

Does anyone know if there's a management strategy for SharePoint development? I've read online that we can make a backup of the development environment and restore to the production server. That might work the first time, but any updates to the production server can't do that without risking data loss on the production server. I've seen some tools out there for migrating list contents, pages and documents from one server to another--although, admittedly, I've not yet investigated them.

But, another concern of mine is custom content types. It seems that once a list is using a content type, you can't update it without deleting the items from the list, disassociating the content type, and reassociating the content type. Shouldn't there be some way to UPGRADE a content type?

Anyway, if you have any suggestions for any of these current dilemas, I would LOVE to hear from you.

Thanks in advance,

Dan

Answer 1

The best way to go is developing with features. Once the features are done, you ca deploy them with Solution package (called WSP).

The only thing left to do is to reactivate those features. That way, you can progressively roll-out new features without having to do everything in production.

WSPBuilder is an application that helps you build WSP.

For automating all of this... good luck. There is a lot of work involved.

UPDATE: Deploying Content Types and Columns are tricky. Once the website has been created, you can't update them anymore through features. You need to go through the code and recursively go through all the sites and modify the specific content type that match the name.

We've tried and it's not possible to do that normally with features. This need to go through something I call "deploying with code".

Answer 2

Thank you for your quick reply.

We already have several features created for our site and a solution package bundling features directed at the fundamentals (content types, columns, etc), and another solution for features having to do with branding (page layouts, master pages, etc.)

But it seems like this is a one-time-shot...basically, it gets our server set up, right? Once people have started using the production environment, we're going to have documents, pages, list items all existing in our content database, and it'll be impossible to update things like content types, columns.

Features you have to deactivate and uninstall before you can install and activate the new feature, right? I've seen a Version property on the feature definition, but as near as I can tell, this doesn't do anything. Solutions seem like they can be upgrade by incrementing the version number, but it doesn't seem to modify things like content types and columns--especially if they're in use. Plus, I'm not sure how extensive the upgrade with solutions is.

There's precious-little documentation out there for this sort of thing. It seems like everything I'm reading is how to get your SharePoint server set up initially...not managing it long term.

Do you have any advice or suggestions?

Answer 3

I recommend taking a look at Chris O'Briens most recent post, and his great Content Deployment Wizard: it's not all about Features!

Answer 4

Maxim is right in that most items should be deployed via features that are wrapped in solutions (WSP files). Your strategy should be to make sure your solutions and assemblies are broken into related bits of functionality. This is also beneficial in that features can be isolated at certain levels like sites and webs. Feature activation code, deactivation code and feature stapling should be used when updating any content updates. Content deployment can also make sense.

Once thing to remember is that if the updates are only in code then the assemblies can be updated without requiring the feature to be reactivated or the solution retracted and redeployed. All that is required is the Application Pool to be reset.

Microsoft has a couple articles on Dev environments and you can Google many others who recommend environments. We do development on virtual machines and deploy most items to an virtual integration server. Once we smoke test it we then deploy our solutions to QA so on and so forth. The benefit i sthat features and solutions are easy to retract. Once it goes out to production it should be thouroughly tested.

Developing in SharePoint has it's issues, that goes without saying, but so far I have found that the benefits outweight the problems.

Team-Based Development in Microsoft Office SharePoint Server 2007

Answer 5

You really really need to define your content types using a feature because that way each content type will have a set GUID and will be stored in the database using the same name. This becomes important when running CAML queries over the site and there are a few other little gotchas when content types are created "will nilly" if you will.

I prefer STSDev for rolling out solutions using custom content types.

There are two ways to edit pages on the server. You can define the page library to have major and minor versions. This allows editors to edit the page and a defined publisher to publish them. This is good on an internal site, but is not recommended for a public facing site.

For a public facing site you will need to use Content Deployment

I cannot stress enough that before going ahead with a production release you make sure you have features for the content types.

As mentioned here, Chris O'Brian has a post saying that you should not use features unless necessary. One of his reasons is that it slows developement.

I disagree with this. Developement is slower if you are unfamiliar with features, but once a level of knowledge is reached, it is not a major factor.

Do listen to him about the backup and restore method of moving the content. If you do that, all mess in the content types and fields and webs you may have created during developement (for me that is always quite a bit) will be moved to your production site.

Instead of having a nice clean site where everything is consistent, you will end up with little bugs and some areas of the site behaving differently to others simply because of old development cruft.

Answer 6

Thank you all for your suggestions.

But we've been working on this site for over a year now. I'm pretty confident that we're already setup according to what most of you are recommending. We already have several features that install things like content types, columns, master pages, page layouts, and workflows. Most of these features are contained within solution packages. We have all of our development environments set up as VPC servers.

So, I have the initial deployment pretty much set. What I'm REALLY hoping to find out is how I can upgrade things like content types and columns and stuff down the road. Is it possible to change content types once they're in use? Because it doesn't seem, based on my initial testing, that this is possible. I'm not to worried about the assemblies because it looks like they swap out just fine, but the only way I've gotten a content type updated is by deleting any items referencing them (i.e. all the pages in my pages library), removing the content type, then re-adding it.

Do any of you know if there's a way to update a content type AFTER the initial deployment? ...when users have already created items based on the content types we've already deployed?

(The other part of my question was actually moving existing pages from the development server to production, but I can live without that. My major worry is the content types.)

Answer 7

We developed a custom solution which would update content types and fields for a Site Collection. Underneath the covers, through code, SharePoint allows us to modify the Fields as well as values in the Fields and Site/List Content types.

For moving the actual content from QA to Prod we use Echo