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.

3 Answers 3


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.

  • Lori - This is what we currently do, but how do you manage project changes which affect the farm (e.g. MySites or profile imports etc.) May 27, 2010 at 9:03
  • Quest has a tool in beta that will allow you to analyze farms and compare them. This might be something useful for keeping all of these configurations similar. You would know what is different and be able to set it up appropriately.
    – Lori
    May 27, 2010 at 13:14

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.

  • What would be some of the reasons for avoiding upgradesolution? (Other than it not installing new features)
    – MBSurf
    May 26, 2010 at 14:07
  • Anders - good points most of which are addressed in our set-up. We know we have an issue in that not all our environments are exactly the same. Projects create new environments in dev/test and then deploy on to the Live infrastrcture which is shared, we only have 1 environment prior to deployment which is 'live like' and invariably SIT issues are picked up here. Not ideal. I guess I was hoping that someone whould say "Ah yes you need the SPConfigManager from CodePlex" but alas.. May 27, 2010 at 9:08
  • MBSmurf: For me its a question of predictability. You cant add new (or remove old) features, add or remove feature elements or properties or change scope. That means u need to have different upgrade path depending on whats changed in the solution. More often than not the operations manager that is deploying the solution has no idea what has changed inside the solution. To have a single way of deploying means retracting & deploying solutions. This also means that you need to think upgrade into your solutions and features from the beginning depending on artifact type before you deploy 1st time. May 27, 2010 at 22:00

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.

  • This is the apporach we are going to have to take. I have looked at Gary's scripts and I think that we will implement this type of managaemnt for all projects going forward. The issue with fixes will never work though as invariably these fixes are required 'yesterday' and there is no way we will get sign off to run them all through 5 different environments before getting them to the end-user. However if we have all the scripts up to date then the Support environment will also be more 'live-like' so this should help with that issue. May 27, 2010 at 9:12
  • Good answer. Should also have mentioned scripting configurations in PowerShell as this is how we have done this on large projects as well. May 29, 2010 at 13:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.