What is your code maintenance strategy for custom SharePoint assemblies?

Question

Howdy,

How do you handle improvements and added functionality to your existing SharePoint code?

Did you deploy your original code as a feature?
Do you create a new feature_V2 and deactivate the original?

What processes have you found that led to problems in the future?

I am specifically interested about WebParts, EventHandlers, and WorkFlows.

From what I can find, MS did not leave a "Best Practices" around updating existing code. (Actually, I'm not sure they left a "Practice" much less a "Best Practices")

You can see other questions around this topic:
how-to-upgrade-a-long-running-sharepoint-workflow-already-in-production
how-to-update-spitemeventreceiver-assembly-version-for-a-list-in-sharepoint
should-i-keep-solutions-and-features-in-a-1-1-ratio

What is your method?

I understand this question may be subjective, but I feel there is a large information gap surrounding this area of SharePoint development.

Thank you,
Keith

Answer 1

We always deploy custom code as features and solutions. When it is time to upgrade the existing code, all you have to do is stsadm -upgradesolution and everything works very nicely. I do not like the idea of having feature_v2 type features around...it makes it extremely difficult to keep track of the current version. I think you should only have one version of each feature in your production environment.

Leave the version control to your source control system.

Answer 2

I'm working at a shop that does a lot of SharePoint development. You want to deploy by feature with a solution package. You can easily upgrade your features as you go along and you will need to upgrade the solution package. This solution package can be created from a TFS Build server with WSPBuilder. As you along, the only thing left is to upgrade the solution and "Force" reactivate your feature to have the new feature of the feature.

Don't forget to do an IIS reset for any new code deployment that is done through the GAC. If you put anything inside like sitemaps and resources inside your 12, you will want to do a stsadm -o copyappbincontent.

If you deploy features that contain application files, you want to unload your application on ALL servers of the farm. It can easily be done by putting an App_Offline.htm at the root of every application on every machine.

When completed, remove App_Offline.htm (or rename it) and you are done. Your site is back online.