Building, Branching, and Releasing

As I’ve developed DotNetNuke modules, I’ve hacked together a simple NAnt build process to handle assembling the DNN install files. This reduced the amount of time I spent building them manually, and drastically cut the “human error” factor. Inadvertently, I was doing a favor to myself by also creating Source zip files (in addition to my Standard and Enterprise license packages). Every build I released had a code snapshot I could later use. To understand how I benefitted, you’ll need some back-story…

My Zero-In store locator module has been very popular, but I get numerous requests for paid customizations or enhancements. One client I’ve done a lot of work with recently opted for Google Map’s premier licensing, something I had not accounted for in Zero-In. I added this to the latest version (baseline) codebase, but one of their sites was on a previous version. The challenge was implementing the change on a previous release, as to prevent negatively affecting the DNN installation and module settings. There really wasn’t a challenge, since I had the source for every version since the module’s inception.

All I had to do was to install the version on a clean DNN instance, unzip the specific version’s Source zip file into the DesktopModules folder (where DNN modules are installed to), fire up the solution, and make the change. The client was happy with the DLLs, which dropped straight into the DotNetNuke bin folder. Still, I got to thinking there was probably a better way.

Branching in Source Control

I use Visual SourceSafe (VSS), since it came with Visual Studio. I don’t (yet) have a reason to go to Team Foundation Server (TFS), and although I’ve heard good things about SVN, I just haven’t bothered. Why fix what’s not broken, right? Anyway, since the previous-version change, I’ve revisited my source control and branching strategy.

My original source control strategy was extremely simple, and although it has worked, I’m making improvements which will benefit me more. Originally, I used the check-in-through-Visual-Studio method, where it creates the SolutionName.root VSS project, then places the solution and project beneath. My original need was just to have a source control repository I could back up, check-in/out, undo, etc.

My new strategy is a little more complex, but having tailored my build scripts to it, will potentially be a life saver. Beneath each module’s “root” project, there are three projects: Baseline, Branch, and Release. Beneath the Baseline project are the Application and Database projects, for the module codebase and database scripts, respectively. Under Release are versioned projects (01.02.00, 01.05.04, etc) for each release, with the Application and Database projects under each. Branch will be similar to Release. My final structure looks like:

Obviously, I have to backfill the previous releases into source control, but I just haven’t yet. The bottom line is that I now will have all releases placed immediately into source control, and can readily branch from previous releases.

Closing Thoughts

I’ll cover the NAnt scripts I use in this process in a later article, because I think there’s some useful information to be had. This will include the file structure, NAnt and NAntContrib tasks, and all that fun stuff.

By the way, you probably noticed the Database project’s sub-projects – Queries, Stored Procedures, Tables, and User-Defined Functions. I’m using SQL Server Management Studio to develop my database procedures, and the SSMS solutions are a great and easy way to manage them. I’ll write something up on the tips and tricks I learned checking that stuff into VSS, too.