I'm about start working on a new SharePoint 2010 project and I have some doubts about the development process. The thing is: as far as I know, all the code development chould be in a continuous integration server, with test and all the stuff, and all the "designer made" clicks should be on "a kind of" scripts that SharePoint has (for example, for building complex lists). I suppose that if everything could be made using code (CSS, XML, whatever) it could be integrated and deployed successfully. But, by the other hand, a big benefit of using SharePoint is that several complex stuff could be made using few clicks in a visual designer, so... it's easy to have all made using code/scripts?
1 Answer
I'd say this is a common problem when it comes to developing solutions to SharePoint in a 'real' environment. With MOSS 2007 it was often problematic to use SharePoint Designer 2007 to perform many of the complex customizations and then move those through the application lifecycle (development, test, integration, production or what have you).
With SP2010 I've tried using SharePoint Designer 2010 as I see it should be used - to prototype and mock up customer needs and wants and then exporting those artifacts as a WSP package to Visual Studio. The problem I often face here is that most of the exported code and XML's are pretty messy and/or include so much useless stuff you don't really want that it would have been faster to create everything manually in the first place.
My current take on this is that I always try to use a Visual Studio-based approach for any customizations. If it seems to problematic I do things on the browser side and export them for further investigation to Visual Studio but mostly discard everything after learning how things should work. In addition using Powershell to script deployment seems to be a big time saver for me!