Above is a typical software environment. The Release Manager controls the release of front-end code and SQL code between the Dev and the Test environments.

Here we are showing a developer committing code changes to Subversion using TortoiseSVN client. Notice the "Skip ReleaseManger" button which indicates the Release Manager's TortoiseSVN plug-in is active for this directory.

Once the developer clicks the "OK" button to commit their changes, a Release Manager Plug-in window appears. Here they can select an already existing request or create a new release request. Creating a request is quick because it only has one required field - the name. They then associate issue items to the request. This will link the issue items to the changed files that they are committing.

Note that the list of issues is being pulled from your issue tracking system and not from the Release Manager database. In the Release Manager you just set it up with a connection string and the SQL text to pull the issues. This allows the Release Manager to work with a wide variaty of issue or bug tracking systems.

Using the TortoiseSVN Plug-in is one way of creating and editing requests, but this is not required. Everything can be edited from within the Release Manager application.

A build can be started from within the Release Manager web application. This is done by selecting the branch to build which in turn controls which issue items will be available to build. In most cases, all of the issue in a branch will be built, but when an issue does need to be held back some reason it just needs to be unchecked. This will in turn uncheck the request or requests that were linked to that issue. This causes the changed files for those requests to be excluded from then new build. So you have control over what goes into the build at the issue item level.

To give you control over the build we provide you with the ability to create variables which will be passed to MSBuild. These variables are defined by you for each project and then you can override them for a given branch when create a build.

These variables make it easy to have multiple branches in test at the same time. For example, it is possible to publish branch 3.3 to web site http://localhost/Northwind:517/ with the database Northwind_3_3 and at the same time have branch 3.4 active on web site http://localhost/Northwind:518/ with database Northwind_3_4. Using output variables makes this easy to do.

When you click the "Build" button from within the Release Manager application the output variables get saved to an XML file. We recommend that you have something like CruiseControl.NET to kick off a build when it sees this file. The output variables in the XML file are then passed to MSBuild or similar tool by CruiseControl.NET. We provide you with a working example of this when you install the Release Manager web application. This is called the Northwind Sample project.

As part of the build all, of the SQL changes are scripted out in a smart way into one single SQL update file. In our example we have MSBuild apply this script to the database defined by the DatabaseName output variable.

The build process automatically generates an HTML report detailing the issues, requests and changed files that went into the build. This can be automatically published to your internal site or emailed at the end of the build.

We also recommend that as part of the build process the build Version Number, Build Id and Build Time automatically get recorded in the front-end code and on the database when the SQL update script is applied. In the image above you can see that the page displays both sets of build version variables under "CODE BUILD VERSION" and "DB BUILD VERSION". It is important to know for sure which builds are in each environment at any given time.

One branching strategy is to have the trunk in Subversion alway contain the code that is currently in production. (The Release Manager works with other branching strategies too.) You then create a branch from trunk for each new release. You might build and release that branch to the Test environment multiple times during the development process. When those changes are done and migrated up to the Production environment you would then collapse that branch back to truck. Before you collapse the branch to trunk you would use the Release Manager to audit the branch. This page shows all of the files that were changed in a branch and if they were included in the last build or not.

The details of the audit give a lot of information on each file, but the most important item is the last grid titled "UNRELEASE CHANGED FILES". This will give you a list of the files that were changed in the branch, but not included in the last build. You would want to collapse the branch without including these changed files because they were not promoted to the Production environment.