One of the biggest challenges that I’ve encountered with SharePoint is that it doesn’t lend itself nicely to the typical project environment, which, at minimum, contain development and production environments. The issues I’ve run into the most are that content and lists are so tightly coupled that it makes it difficult to perform design changes without performing a content freeze on the production environment. For example, if I have a list with calculated columns and wanted to add some new functionality, I would have to do a content freeze on the production server, create a list template (including content) from the production server, restore that list to the development environment, make my changes, then reverse the list template process. The same holds true for pages and just about anything else in SharePoint. It seems as though once the site is deployed, it’s best to work directly on the production box, but that breaks a ton of best practices, for obvious reasons.
How are some of you other SharePoint developers handling this limitation?
There are really two (more?) levels to SharePoint ‘development’. You have the code which gets deployed to the server, such as web parts, content types, workflow actions, etc. This works relatively well in terms of deployment and best practices.
Then you have your example, which is more of a customization of site instances. What we’ve done when we had to customize a calculated field in the Portal’s Site Directory list, is to try and tweak the changes in development. Then write up detailed instructions of the customization to be made, and have a separate person with appropriate permissions use those instructions to make the change on an integration (staging) server. Then have the same person makes the changes live on the production.
I’m not sure if your changes are susceptible to this approach, but it’s worth considering.
Then we have another site which is heavily customized with SharePoint designer, and that one we work live on.