Unlearning My Development Process

Two years - that's about the length of time I have been developing on the SharePoint 2007 platform. Over that time I have been using roughly the same development process and tools, with a few additions to my "tool-belt", and a few tweaks to the steps in the process. But no radical shifts.

Must admit I have always developed from the point of view of creating a deployable solution first, and adding functionality to that solution as I go along. Means that when the functionality is working and tested then I have a package ready to ship. Rather that than developing the packaging as a final task, and then needing to retest the deployment outcomes.

And I like CONTROL over the solution, so I have been hand-crafting some of the solution files. You know the ones - the ones that WSPBuilder hides away. I did try that tool some time ago, but had problems with certain complexities in solutions, so returned to my old ways.

Well, it's time to kick that habit and learn something new! So now that I am starting a major new project I am also trying out a new approach to my day-to-day SharePoint development. First change is to incorporate SPVisualDev from the very start, and I must say I am really impressed with the ease it offers in adding fields, content types and lists to features. It even makes adding resource files nice n'easy, so encourages me to build the features ready for localisation if required in future (I know, I know, "YAGNI", but given that the tool makes this capability easy I'm all for its inclusion).

Then I am using WSPBuilder to create the WSP files (though am disabling the "Cleanup" operation so I can still get to the manifest.xml and ddf files if necessary!).

So far so good. Now all I need is a tool to generate a batch file with the appropriate stsadm commands for deploying a set of WSP files, and I'll be "sweet as, bro" (it's a kiwi thing!)

I'll let you know what else I change for the better.