1.>
SharePoint Dispose Checker Tool - Run the SP Dispose Checker Tool on all custom code you write.
SPSite & SPWeb object has a big load and we need to ensure dispose is always called. 2 easiest ways to ensure Site and web objects are always disposed are shown below:
SPSite site;
try
{
site = new SPSite("http://demo1"); // Create the SPSite object
...
}
finally
{
if (site != null) // Check if the SPSite object exists
{
site.Dispose(); // Clean up the SPSite object as it has not be disposed of
}
}
Alternatively I prefer to use using statements
using (SPSite site = new SPSite(http://demo1/))
{
.... // SPSite.Dispose method will be called always
}
Run the
SPDisposeCheck tool on all code before deploying outside of you development environment, this can be
automated into VS 2010.
2.> Have at least 3
environments i.e. don't send code from the developers machine straight into production. Sandboxed solutions alleviates this risk to some degree but use a UAT, pre-prod, QA environment. Your deployment environment must mimic production as closely as possible i.e. ensure there is a separate SQL DB, all versions of software are identical, load balancing is setup. Have documented
change control. Try perform changes through scripts not manual changes if possible. Web.config changes need to be replicated to all servers on the farm so doing the change manually is not the best option. Change the
web.config via code to ensure it is done through the configuration database so they are changed on all web.config's in the farm.
3.>
Error handling,
catch errors as specifically as possible, die gracefully and appropriately, log the errors, check the production error logs periodically.
4.>
Deploy code using wsp solutions. Ensure code is not in
debug mode when compiled, it runs slower and potentially can crash/holdup your production environment. Implement
CAS, deploy to bins if possible and apply CAS security policies to custom coding.
Perform peer code reviews, it ensures coding standards are being followed, developers learn from each other, bugs are often picked up pre-testing and it increases team members knowledge that reduces maintenance costs.
5.> Develop using
source control no matter how smal the dev project is. Preferably TFS 2010 but
VSS 2005 is even fine, failing this use CVS, IMB/rationals ClearCase for source control. Also have
bug tracking with TFS the integration is excellent between the bugs and the source control. I.e. use TFS if possible.
6.> SharePoint projects are often very good candidates to SCRUM or other agile
methodologies. Use them if it's appropriate. Traditional formal SDLC / waterfall approaches tend to work well on the larger SharePoint projects.
7.> Use the
developer dashboard.
8.> Unit testing - don't test SharePoints API, test your custom code. In MOSS Type Mock isolator was a great product for SharePoint I presume this is still the way to go. Andrew Woodward is a good blogger on SP unit testing.
