Best practices for applying changes to a SharePoint application

Question

I feel like I need a better defined framework for updating my SharePoint (MOSS 2007) application with custom code changes. I am creating wsp solution files with features and new types and such, but once those get tested and deployed, I feel like it's a bit of a leap of faith, and that makes me nervous and occasionally reluctant to deploy changes. After deployment, it's difficult to correlate the current state of the SharePoint application with the specific code that is deployed on that SharePoint server. What features are actually installed and on which sites? Which features are activated or deactivated? Which version of this custom field or content type is really there? Things like this. If an error crops up, I have to rely on my assumptions about what code is there and actually running, or I have to spend time digging through deployed assemblies and the 12 hive -- not impossible, but pretty unpleasant.

What steps should I take to improve my ability to unambiguously determine the state of the application and find the code that truly represents that state? Are there third-party tools that can help with this?

Answer 1

Unfortunately the SharePoint development experience is lacking in this regard. As long as you are "namespacing" all features deployed using solution packages, you can use solution management from central admin to keep track of versions, and what gets deployed to which site collection.

Features are scoped from all levels from the farm to an individual web; so maintenence from that level is a little tough. I just try to organize all deployed code from the (top down) solution level.

It gets even more complicated when deploying custom timer jobs, event handlers, etc; I really hope that version next will address a lot of these common developer concerns.

Answer 2

I feel your pain... Application Developyment Lifecycle with SharePoint 2007 leaves me with a bitter taste in my mouth.

To answer your question. We built our own deployment utility that does a few things for us.

1. Checks state of key Timer Jobs (too many times we would do a deployment to find one WFE that did not get deployment)

2. Checks state of key Services on all our web front ends (again we want to know health of farm before we start kicking off timer jobs).

3. Shows file version and date of selected assemblies from GAC (does this across all Web Front Ends). We have seen problems before where assemblies did not get installed correctly across the farms.

4. Updates web.config settings based on an custom XML scheme we provide. We ran into some problems with web.config updates so we have thought about creating a utility to validate the web.config (specifically make sure there are no duplicate entries for specific keys).

5. Push content type updates (first time content types are deployed via feature it works great, but as soon as you need to update that content type it gets tough).

6. Checks status of WSP package after deployment or upgrade.

This utility uses the SharePoint API to do most of this work. Some of it is done by checking WMI Events.

Answer 3

Isn't the only way that you have a planned/controlled deployment process and a version management system like TFS

In the current project I am involved in we have:

1. Continuous builds
2. Daily Builds on a development server
3. When we release something to test we merge the code to the Main bransch in the version management system (TFS)
4. When tested and ready for production then we merge the main bransch to the release bransch

Using this structured way we always knows what is deployed in what environment and can also track all changes based on environment or changes in requirements(are also tracked in TFS)