Setup a basic Continuous Integration process

In this tutorial I'll show how you can get a basic (and free) Continuous Integration process up and running for your Visual Studio project on a windows machine. We'll use Subversion for version control and Team City as our Continuous Integration Server.

Version Control

Visual SVN Server is a great way to get a Subversion service up and running really easy. Download it here.

Start the installer and choose to location where to install Visual SVN ('Location') and the folder where your Subversion Repositories containing your versioned files will be stored ('Repositories').

In this tutorial we'll use the Subversion authentication.

After the installation is complete, fire up the Visual SVN Server Manager (located in Computer Management) and a user for the build process f.e. 'builduser' by clicking the link . Don't forget to add an account for yourself as well.

Create a new repository by right clicking the 'Repositories' node, make sure to check the 'create default structure' box. Some extra information about Subversion can be found in this free book.

Add the users that you made before to your repository via your repository's properties.

Verify that your Visual SVN Server is running by right-clicking your repository and selection 'Browse', you'll need to provide the credentials of one of the users you added before.

Committing your project

Now that you have our version control server set up you'll need to commit your project into version control. To do this you'll need to install Tortoise SVN to communicate with the Subversion (Visual SVN) Server, this can be downloaded here. Tortoise SVN is a Subversion client which is integrates into the windows explorer.

Please install Tortoise by following the steps of the installer.

After you've installed Tortoise you are ready to commit your project. Right click your solution's folder and select 'checkout'. Fill in the 'URL of the repository, this is location of the the repository you created in the Subversion server.

You can easily get this URL by opening the Visual SVN Server Manager, right clicking the 'trunk' folder of your repository and select 'Copy URL to Clipboard'. Make sure that the URL points to the 'trunk' (the trunk will contain the latest version of your source code).

After pressing ok, providing your credentials and accepting that the folder isn't empty, Tortoise will create a hidden .svn folder (which contains the status of your files).

You might notice that a red ball with an explanation mark is highlighting your solution's folder.

Right click again on the solution's folder and select 'SVN commit'. Now select only the files of your solution that are needed to compile.

After pressing OK, you've committed your project.

Continuous Integration

Ok, now the fun part! Getting your Continuous Integration process up and running.

Please download the free Team City Professional edition here and follow the steps of the installer (When you're doing a local install and running vista start the installer as administrator).

When the set up is complete it will automatically open your browser and point it to the Team City Dashboard. Accept the license agreement and create an administrator account.

Create a new project by providing a name for it.

Add a build configuration. Fill in the name, the rest of the settings can be left default.

Continue to the VCS settings and 'Create and attach a VCS root'. Select 'Subversion' as the type of VCS and provide the necessary 'SVN Connection Settings', the URL as the same as the one we used to checkout with Tortoise earlier. The rest of the settings we can ignore. Test and save the connection.

Set the VCS checkout mode to 'Automatically on Agent', leave checkout directory blank, check 'clean all files before build' and continue to 'Choose Build Runner'.

Select 'sln2008' as your 'Build Runner' (or sln2005 if you've got a 2005 solution). Provide the relative path to your .sln file. In the case of this tutorial this is './MyProject.sln'.

The rest of the settings can be left default. Save the configuration and select 'Build Triggering' (number 4) on the right side in the 'Build Configuration Steps' menu.

Check the 'Enable triggering when files are checked into VCS' box and save the configuration. This will make sure that whenever someone commits a change into Subversion the build will be triggered.

Now it's time to run the build for the first time (manually to see if it works)! Click the 'run' button on the top right of the screen (above the 'Build Configuration Steps' menu).

Select the 'Projects' tab on the top left and check of your Project has compiled successfully.

Now make a change to your project so that it contains a compilation error and commit this change (by right clicking your project folder and selecting 'SVN Commit'. The file you changed should already be selected.

After you've committed your file watch the Team City Dashboard and check that your build is triggered (it may take a few seconds, refresh a few times) and that it fails because of an compilation error.

Fix the compilation error and commit again. Now you'll see that after the build is triggered the build succeeds again!

Done!

Ok, so that's your very own build process! In a next post I'll show how to get your unit tests into the build process.

Proxy Product Owner

After reading Przemyslaw's blog post about a Customer Team Member, I decided to write down my own experience.

In my current Project we work with a Proxy Product Owner. The reason why we do this is because our project's stake holders are representatives of several regional companies. Every regional company has their own vote in the matter.

Since we do want a single product owner on site (most of the time) we decided to introduce one of my colleagues as the product owner. In workshops together with the stakeholders he formed a vision of the product we needed to build.

After each sprint (we have sprints of 3 weeks) there is a workshop where new functionality is shown and upcoming features (highest in the backlog) are discussed. During these workshops we at least have two of our developers present.

In my experience this works very well. We have a product owner we can easily communicate with and has a clear understanding of the wishes of our client.

Script your SQL Server database

One thing that I found that the SQL Server Management Studio always lacked was an easy way to script a database. Basically I wanted it to able to do the following things:

Generate SQL scripts for the DB Schema

Generate Insert statements for the data

Generating the schema was doable using the Script Wizard. Scripting the data in the form of INSERT INTO statements can't be done very easily (as far as I know).

Previously I have always been using SQL Scripter for this, but since a while this isn't free anymore (though 79€ isn't that much money).

A colleague pointed me to an open source project at Codeplex named SQL Server Hosting Toolkit and this exactly fits my needs.

It is a very simple tool which makes it possible to script your database (including data) through:

• Graphical interface
• Command line
• Visual Studio 2005 plugin

The command line option makes it an excellent tool to use it in a continuous integration build or automatic deployment process.

P.S. I know that Red Gate Software has some interesting tools that might do all this as well, but I must confess that I haven't tried those yet.. (and those aren't free either :-])

Agile Business Conference 2008

More then a month later I finalized my summary of the conference. After writing a Dutch version for the company newsletter, I realized this would be a great time to start with a blog.

So without further delay here are, in my opinion, the topics that were talked about the most during the Agile Business Conference 2008.

Communication

An import aspect in successfully adopting agile is 'communication'. Several presentations mentioned that in a lot of companies there is a gap between 'the business' and 'IT'. To make agile work (and software projects in general) this gap needs to be closed. Especially because (in most cases) IT is a import part of the business (generates value).

Realism

Agile is not a silver bullet. It is method that can help you in many ways, but this shall always be dependant on the organization and the type of projects in which it will be applied. Having said that, it is important that we give the choice, of which development method to use, some proper thought.

Feedback

A recurring theme within several presentations is the feedback agile methods will give you. For example:

• Unit testing - feedback at developer level.
• Short development cycles - at customer client level (Rob Thomsett explained that customer is a swear word :))

Agile transformation

There are different approaches for transforming an IT organization to agile, top-down, bottom-up. Borland used a top-down approach where they started in one team and used the scrum master of that team as the agile evangelist to help other teams move to agile. Because upper-management fully supported this idea (but didn't make a mandate out of it), a large part of the organization is now using scrum. Even a team that was really skeptical asked for the help of the evangelist to help them with implementing scrum. Switching to agile is a change process, it doesn't happen overnight. The rate in which the company will change is totally dependant on the (culture of) the organization.