Notice all of the steps are listed on the left hand side. Nothing is actually saved to the database until the "Save" button is clicked on the last step. The first step in the wizard is to enter basic information for the project. We will be using Northwind project as an example.

The next step is to define the Sources for the project. You will normally be defining 2 sources, one for your front-end code and one for your database code. Each URL will point to the branch directory in Subversion.

First, lets look at how the directories are organized in Subversion. Notice that under the Northwind project there are 2 child folders, DB and Web. Under each of those is the parent folder to all of the branches (called "branches"). Under this example, "trunk" is used to hold the latest version of the project that is in production and all active development takes place in one of the child folders of svn/projects/Northwind/Web/branches or svn/projects/Northwind/DB/branches.

When you first enter the Sources step of the Project Edit wizard no sources will be defined.

Once you click "New Source" you will be show a form to enter and test the source information.

Here you give it a name, usually something to indicate if it is the source for front-end code or database code. You check the "Is SQL" box if it is the source to database code so the system knows how to build the files from this source. Database files get combined into a single SQL script file, and front-end files are pulled keeping their directory structure.

You enter 2 URLs which may or may not be the same. When entering a URL it is important that you match the case that Subversion has. Some processes work in a case insensitive way and some do not.

The first URL is the URL that the ReleaseManager application will use to access the files in Subversion. This is the full URL to the parent of the branches for our project. In our example this would be: file:///C:/svn/projects/Northwind/Web/branches.

We recommend for performance reasons that you connect using the "file://" protocol instead of "http://" or "https://".

It is important that you test the URL at this point to make sure the web application can get to Subversion. When you click "Test" you should see the sub directories that are under your branch pointed to by your URL.

The second URL is the URL that developers use to access Subversion with the optional TortoiseSVN plugin. This could be the file access method "file://", "http://" or "https://".

Once you have source defined for your front-end and database branches your Sources step should look something like the following:

The next step in the Edit Project wizard is "Issue Tracking". Here you give the Release Manager application a connection string to your Issue Tracker database and the SQL to get the issues for the project. Optionally you can enter an Issue Tracker Link that will allow the developers to click on an issue from within the Release Manager application and it will open that issue in your Issue Tracker. This is optional.

The connection string is straightforward but it is important that you test it to make sure that it works from the point of view of the Release Manager application.

The SQL you enter is the SQL to retreive the issue items for the project you are defining. You are defining the columns that you want the user to see when they are assigning an issue item to a release request. The first column must alway be the ID column for the Issue Item or Bug.

For the WHERE clause you can use place holders such as %u for the current user name, %b for the current branch, etc. It is important that you also include the place holder {0}, which will be valued with the already assigned issue item ids when the release request is edited.

We give 2 examples here. So in our first example we define the SQL as follows:

At run time this will value the place holders and look something like:

This will present the results of the SQL to the user when they are creating or editing a release request. Notice in the raw sample result set below that an extra column named "Include" was automatically added. Also note that the last row does not match the WHERE clause except that it was one of the IDs previously assigned to the request that I am currently working on.

Keep in mind that this list should be used to present the user with the most likely list of issues that they would want to assign to a release request, but they always have the option of adding an issue item that is not on the list by just providing the Issue ID.

The next step is where you assign the rights that each user will have for this project.

You can give a user rights to make release requests for the project, the right to build the project or you can give them read only access (this is normally for a person that is not a developer.)

The next step in the wizard is where you define build variables. Again this uses place holders, so the first variable below is "C:\Builds\%p\%b\%i " which will be valued at runtime to look something like "C:\Builds\Northwind\3.3\281".

The SYSStartSQL and SYSEndSQL variables are used to add SQL to the start and end of the SQL file that gets built. This is usually used to log the fact that the script has been applied. Example: INSERT INTO BuildLog (BuildTime, Description) VALUES (getdate(), 'Build %b_%i Started');

The next step in the Project Edit Wizard is Output Variables where you define variables that will populate an XML file that is created when a build is created. This file it will be named based on the value in the SYSCCNetXMLFile variable in the previous step. The variable you define here will be the projects default values, but the user has the ability to override them at build time.

Note: we are using MSBuild here as an example. You don't have to use MSBuild, but it is recommended that you automate the build in some way.

We created 2 variables below. These will be read by MSBuild to know which database to apply the SQL script file to and which email address to send a status update to.

The final step is to save the project. Nothing is saved to the database until this step.