Best Practices: Sharepoint Application Development Life Cycle

As you might know SharePoint Application development life cycle is different if you compare with  asp.net application development.
I bumped on the the question after the first production release : "What next? How we can perform our development,testing and deployment any further?"

There is no easy answer. Recently I happened to be at the Sharepoint Best Practices 2010 in Washington DC and got a chance to ask the experts the same question which was nagging me since the the first release on my production.

 Here is some recommendation that I have - every an update should be packed in the new wsp file and must deliver all changes that I want to make over the Prod. Why it so? because it's safe to keep the original feature  set which was used to create a Prod site. It's safe for list feature and also for Workflow features.

So the first rule: Never retract the original a wsp file on the Prod. Here is the wonderful recommendation from my SharePoint star - Professional Sharepoint Development. Every release is a new wsp file.

In case you need to change the structure of the list which has been already created from you list template feature-  do it through Object Model, don't modify a schema.  An update schema file after very first list has been created is unsupportable and may break the list instance. So to soothe the pain - use the feature for content types and custom feature receiver to propagate the changes to the list level. In you custom list template feature reference to those content types.

 the first rule in the real world: Even I know that is bad to redeploy the original wsp I am still doing it!

 to make the upgrade of the existing site I have adopted the concept of the release feature

The second rule: Never change the schema for the list template feature if the list instance has been already created. Do all your changes through Object Model.

In case you are unfortunate enough and you have a code-based Workflow on your site. If workflow needs modification, you have to be aware that serialized workflow instance might not be able to wake up using your new workflow dll.

The third rule: Don't change the original dll for Worklfow. You always should keep the original dll in GAC. Every workflow modification should be packed in new dll and new association should be made to use it.

A few days ago I have been delighted to discover this practical guidance - this is free and made initially for internal use but then converted as general public hands-on best practices "how to develop a sharepoint project". Some of the chapters I don't really agree on, but it's just my personal opinion.

Found a  useful  scenarion in MSDN: Upgrading the Training Management Application