1. Stick to the product if you can. SharePoint provides a lot of functionality out of the box - focus on these quick wins and don't immediately switch over to Visual Studio and start writing code.
2. Built to last SharePoint projects are in continuous evolution so you need to develop in such a way that it is easy to evolve and to extend. Take a look at site definitions vs site templates for example.
3. Do not GAC every web part you develop. By the way, there are number of SharePoint development artifacts which you need to add to the Global Assembly Cache (GAC) such as receivers -feature receivers as well as other event receivers - timer jobs and workflow assemblies.
4. Keep your custom site definitions as minimal as possible. A long debate started after Joel's post on the topic - Do you really need a site definition . They are nothing more than a "skeleton" for attaching programmatic elements in the form of features and should be deployed as solution packages.
5. Do not touch the production server's file system. Yes, if you need to deploy something you really need to wrap it up as a SharePoint solution file (wsp). Check out Creating a SharePoint Solution Package in Windows SharePoint Services 3.0 as well as my own post from a while ago - WSP - SharePoint Solution Files. Don't forget to take a look at WSPBuilder
6. Features are your friend . Features can be added to sites as needed. You can even force their deployment through stapling them to existing Site Definitions. Features can be activated, deactivated, and even upgraded, on existing sites.
7. Thou shall not use Full trust in vain. Changing the trust level in the web.config is just stupid for anything other than debugging. So learn to use SharePoint Code Access Security policy files.
8. Stay out of the database. The SharePoint database schema should not be altered in any fashion or you will lose all support in case of an incident. KB841057 - Support for changes to the databases that are used by Office Server products and by Windows SharePoint Services. I think it is also safe to not directly read from the database – SharePoint provides you with multiple methods to do exactly what you need – stsadm, the object model, web services or WSS RPCs so there’s no need to read directly from the database.
9. Use different development, build, test, staging, and production environments. Take a look at the SharePoint application life cycle from the P&P SharePoint guidance. If you are unsure about the why and how.
10. Be your admins friend You can make deploying a SharePoint solution very easy for your admins using SharePoint solution packages, together with powershell and/or stsadm extensions. Or can make his life hell – remember this quote from JThake - “Mr SharePoint Solution meets Mr XCopy in a bar and kicks the living sh*t out of him” (Jthake)
PS These commandments are not listed in order of importance… if you have some other ones – please add a comment.
5 comments:
LOL thanks for the quote! ;-)
Great list!
11. Thou shall want to have a bloody good reason for not using WSP files to deploy stuff :-)
Perhaps to be included above in 'not touching the file system', thou shalt not edit web.config by hand.
I would also add "think of what the heck is the functional necessity of doing this thing you are doing".
Great post. I'll share this with my friends :))
Post a Comment