In the past 5 years I’ve worked on quite a few projects and I’ve seen quite few SharePoint Developers/Consultants/Architect delivering solutions. I started in London
What is the best way of deploying SharePoint Solutions?
In general if the my customer wants a new website or intranet I deploy my new projects as a Partial Site Definition. (See Mirjam’s blog on Site Definition vs Web Templates) I still don’t trust Web Templates as a method to deploy my solution to the customer. For the simple stuff, yeah Templates are no problem, but as soon as it gets a bit more complicated it might not work and then I found myself too often just stuck.
A couple of basic things that should always be done:
- Deploy your solutions as a solution file.
Use Field Definitions, Content Types, List Definitions
Everything is deployed using features within the solution file. Manual configuration steps should be avoided.
Warn the customer not to change anything that has been deployed manually. (They don’t understand this in general anyway 😉 but at least we should attempt to control the deployment process a bit)
In SharePoint 2007 I used to use WSPBuilder to create my solution files and then use Solution Installer to make it easy to install the solutions. After an initial deployment visiting my customer, they would be able to do any following installations.
Then I started to look at upgrades of existing solutions in SharePoint 2007. Do you create a new solution file with features that include code that sort out the upgrade or do you update the existing solution and redeploy the whole solution. I’ve always found this a risky business. Even if it works in my develoment environment is the upgrade going to do what it needs to do when the customer installs the solution?
In SharePoint 2010 you can now run features that upgrade from previous versions of that feature. Things are getting a bit more comfortable however, I’m still worried about customers changing parts of the solution manually within the browser or SharePoint Designer. Potentially I’m going to undo things that they have changed.
This is what I’ve started to do for almost every project now.
Split my solution into the following solution files:
Look and Feel
In my core module I include
- Web Parts
- List Definitions
- Content Types Definitions
- Field Definitions
- Global Images
- Error Handlers
Look and feel
- Master Pages
- Event Handlers
- Timer Jobs
I’m sure that there is still some bits missing in the above, however this should cover 90% of most projects.
One of the bits missing is resource files. Where do you keep put the resource files. I’ve always found resource files a good tool to use, however it does add a lot of extra work.
Resource file have to be deployed before they get used. Therefore it might make sense to add resource files in the Core solution. More and more I believe that this is not the best place for my resource files as an update to the Code module results in a redployment of the Corfe module which hold the resource files.
I’ve now ordered the installation order of the 4 modules as follows:
2nd Look and Feel
Each module has it’s own resource files (if required). Resources from modules which have been installed earlier can be used, however if a module requires a new resource then I’m adding it to that module.
e.g. if an Event Handler in the Code module needs a resource file entry for the feature name then this will be stored in the resource file for the Code Module.
There is so much more about setting up SharePoint projects and deployment but I leave that for a next time.