Managing Changes to SharePoint Configuration

Question

We have 5 seperate environments which code needs to move through within the project lifecycle (6 if you count individual developer VMs.) This does not include the support enviornments which are used for fixes in Live.

The problem we have at the moment is managing the changes that a given project might make to the platform (i.e. Central Admin) and how to migrate these changes across all environments.

Another related problem is how the support team can handle fixes applied to Live and how these can be replicated back through the project environments.

At any one time we should be able to produce a document or run an automated script to restore the current configuration for a given environment.

Another problem here is whatever solution is used is going to have to be controlled (in some manner) through Rational Clear Case as this is the tool which our support and deployment teams use.

Any advice, links, blogs, contacts, people to have a chat to, anything really would be very very helpful.

Answer 1

Have run into this same issue many times. As an Admin, one of the ways I've tried to manage it is to make sure that every custom solution is packaged so that the packages can be deployed via stsadm (or PowerShell for future 2010 stuff). Also have also maintained that each solution should be created on a site that is in a site collection database of its own. That way, if there is content that will need to be migrated with the solution, you can just attach the content database to the appropriate web application in each environment. It also allows you to back it up and restore it repeatedly so it can move both up and down through the environments that are part of your lifecycle. It doesn't always work, but it's been what I have used in the past and in general allows you to move a little easier.

Answer 2

Its a broad topic, and easily one that could be split up in several questions...

First and foremost (as Lori mentions also) solutions and features where applicable is a must if you want any degree of control with changes. As Lori also mentions, deploying these solutions should also be wrapped in scripts so that the API og stsadm usage is consistent (eg. not using -force, and avoiding upgradesolution).

I want to be sure I understand what you mean by "handle fixes applied to Live and how these can be replicated back through the project environments.".

The whole point (IMO) of having 4-5 environments (x dev environments, devtest, integration test, preprod, prod), is that changes need to be introduced in the dev and test environments before being allowed to be deployed to the production (Live) environment. The purpose here is to find out if the one bug thats squished a) is really fixed, b) has introduced new bugs in the module, c) has introduced bugs in related modules (hence integration test).

You also need to think your whole application life cycle into your features. They should be upgradable (in SP2010 this has become much easier) so that things doesnt break if you "upgrade" them -depending on artifact type this usually involve code-bloat in feature event receivers.

As said above the whole ALC story is much better in SP2010 where you have BindingRedirects that enables assembly versions and feature versioning and upgrade. You can also define dependencies on solutions.

Answer 3

Good question, the SharePoint solution framework helps manage many changes in a consistent, repeatable manner but doesn't cater for some farm level configuration such as search scopes, managed properties etc. To manage these types of changes I recommend scripting this configuration using stsadm and extensions such as the ones provided by Gary Lapointe. For example there are several commands to manage audiences, manage search and many others.

I have used this approach on several large projects, creating custom stsadm commands where required, to fully script all installations. This does require a bit of up front effort, but pays off during deployment as you can be sure each environment has exactly the same configuration. This also makes it a lot quicker to get developers up and running on a project, or rebuild an environment as you can simply run a script to ensure they have all the latest changes. To do this we maintain two scripts - a 'build from scratch' script and a 'latest deployment' script. When we need to make an environmental change we will add this to the 'latest deployment' script and if required the 'build from scratch' one. After a successful deployment through all environments we will clear the 'latest deployment' script.

If you are creating a new SharePoint environment you could also look at scripting the installation from the OS up to be even more confident that the environments are in sync. In this case you can use psconfig as well as stsadm to install and configure the farm. Again this requires a bit of work but saves time every deployment and helps reduce time spent fixing environmental problems and the 'but it works on my machine' excuse from developers.

In regards to ensuring fixes to live are replicated in the other environments I would suggest that these should be first made in development and then rolled through the test environments first. This way you can be sure the fix does not have any adverse affects before applying it to the production environment.

Additionally I haven't used Rational ClearCase but as the scripts are just batch files or PowerShell they should fit into version control fairly easily. I've used TFS to store these files which also integrates well with MSBuild for integration/nightly builds to automatically rebuild an environment each night so you can test the changes and deployment as the project progresses.