Eric Charran of Microsoft recently published a MSDN article covering team-based development on the SharePoint 2007 platform. Eric begins by delineating the roles of artifact development and assembly development, discussing environmental and procedural similarities and dissimilarities. Eric’s article then covers integration builds and deployment processes, with the aid of some well-designed illustrations. Overall, Eric’s article is informative, and should be read by anyone seeking a high-level understanding of team software development on SharePoint.
For a few years now, our software engineering team here at SharePoint Solutions has been using a development environment similar to what Eric describes. Because we are geographically distributed, we rely on local virtual development environments (robust Dell laptops running Virtual Server 2005 RC2), that connect to Team Foundation Server over VPN. Prior to TFS and VPN, we used Visual Source Safe with SourceGearSourceOffSite and CruiseControl.NET. SourceOffSite was (barely) a workable solution, but now seems like the dark ages in comparison to Team Foundation Server. As for the source code vault itself, we take the approach of using a common mainline for team builds, with each of us working in isolated virtual build labs for incremental building and testing. We merge from our independent VBLs to the common Mainline, and kick off team builds for testing and release.
We are primarily focused on producing software solutions for redistribution, so every artifact and assembly we create must be packaged for deployment. In Visual Studio, our solutions are comprised of modified C# class library projects which have been customized to output SharePoint deployment packages (.wsp). Although the VSeWSS toolset has some nice conveniences, it just doesn’t provide us with the granularity we need for packaging commercial applications. A simple example of how we structure a project can be found in my October 2006 post Anatomy of a SharePoint WSS v3 Feature Project in Visual Studio 2005.
Finally, we depend on the WiX toolset for creating Windows Installer packages to distribute our software products. Here too, we use modified C# class library projects which have been customized to output MSI setup packages. The last step of our team build process zips up the appropriate outputs, then places them in a staging area where they await manual release to web (RTW).
