How do you handle code promotion in a Sharepoint environment?

Question

In a typical enterprise scenario with in-house development, you might have dev, staging, and production environments. You might use SVN to contain ongoing development work in a trunk, with patches being stored in branches, and your released code going into appropriately named tags. Migrating binaries from one environment to the next may be as simple as copying them to middle-ware servers, GAC'ing things that need to be GAC'ed, etc. In coordination with new revisions of binaries, databases are updated, usually by adding stored procedures, views, and adding/adjusting table schema.

In a Sharepoint environment, you might use a similar version control scheme. Custom code (assemblies) ends up in features that get installed either manually or via various setup programs. However, some of what needs to be promoted from dev to staging, and then onto production might be database content that supports the custom code bits.

If you've managed an enterprise Sharepoint environment, please share thoughts on how you manage promotion of code and content changes between environments, while protecting your work and your users, and keeping your sanity.

Answer 1

I assume when you talk about database content you are referring to the actual contents contained in a site a or a list.

Probably the best way to do this is to use the stsadm import and export commands to export and import content from one environment to another. (Don't use backup/restore when going from one environment to another.)

Answer 2

For any file changes (assemblies, aspx) you can use Features and then keep track of the installers. You would install the feature and do an upgrade to push changes.

There's no easy way to sync the data...you can use stsadm import/export commands as John pointed out. But this may not be straight-forward, especially if the servers are configured differently.

There's also Data Sync Studio product (http://www.simego.net/DataSync_Studio.aspx) you can try.

Answer 3

Depending on what form the database content takes, I would keep the creation of it in code so it's all in one place (your Visual Studio project) and can also be managed via source control. Deployment of the content could either be via a console application or even better feature receiver.

You might also like to read this blog post and look at the tool mentioned there for another approach.

Answer 4

The best resource I can point you to is Eric's paper:

http://msdn.microsoft.com/en-us/library/bb428899.aspx

I was part of a team working to better the story around development of WSS and MOSS solutions with TFS, but I don't know where that stands.