2-3 months ago, I have deployed the application I was working on the client. Since then a lot of changes have been made and I did not work on this project. The database changed significantly but the sql script have not been updated with the latest changes. Now, I have to get back on the project to make an update to the client. I can generate a new set of scripts to create a new database, but how am I suppose to update the production database …

Before I left, I gave instruction on how to version every changes to the database. I wanted to have scripts with every changes that have been made and then run them on the client on future update.

Let’s see the pros and cons of not doing so :

PROS :

• Save time when developing

CONS :

• No way to easily update an existing database
• Loose time trying to figure out what is changed
• No confidence that you will update the existing database correctly
• No way to get back in time if needed

Please, version your sql script! It will be much easier for those doing the futur work.

What is TeamCity? It’s a software that you would use to do continuous integration. Continuous integration is very important and it should never be an option on a serious project (that’s is my opinion and I strongly believe in the values it provide).

If you have followed the Building A New Application Series, you may be wondering why I would want to do that after setting up a complete integration server with CruiseControl.NET. Well, I was skeptical when I first heard about all the fuss surrounding this JetBrains project. After all, CruiseControl.NET was doing everything I wanted and more.

So the reason I made the switch is because of the time it take to set it up : 20 minutes. Everything was fully functional in under 20 minutes. I absolutely got no error at all. I just got through all the step of the wizard and then : done. Unit testing, code coverage, build, reports, etc… And it’s absolutely free for small team.

The big downside for me was the lack of support out of the box for other unit testing framework (other than NUnit and MSTest). My project is using MbUnit so I will need to do some more research to integrate it in my build process. But it is possible if you want to invest time in doing so.

So let’s get started with this little tutorial :

1. Download TeamCity.

2. Start the installation.

Just follow all the steps. I encountered a slight problem due to something already on port 80, so I used the port 8080.

I left everything intact in this screen, but this is where you specify some default folder used bu the build agents. The tempDir and workDir will be used to store your application artifacts and even your source file before the compilation if you don’t give it one in the configuration (later).

That’s it, you have installed TeamCity. Now let’s add our project to it.

3. Open TeamCity !!!

Nothing too complicated here, just enter the username/password you want for the administrator account. The email will be used to sent important information the build server would want you to know..

What I like is that you will be taken by the hannd for the rest of the steps. Click on the Create Project link.

Name of the project and a description. It will be useful if several projects are on the same build server.

Now click the Create build configuration link. You can have multiple build configuration by project.

In the build configuration window, you can change the way the build number are generated and the default behavior when the build fail. You can also specify that you want to start with a clean project.

There, you can decide how you want the project to be retrieved from the source control repository and where to put him. You can also decide when to label your build. If you do not want a label on a failed build, you can do so. Next, click on Choose build runner.

TeamCity is not only for .NET project. Several build runner are included such as MSBuild, NAnt, sln2003, sln2005, sln2008, Ant, Maven2, etc… Because I am using MbUnit as a testing framework I have decided to stick with MSBuild. But if you are using NUnit or MSTest you may want to use sln2003, sln2005, sln2008 as they can run your unit tests and tell the coverage of your assemblies. You need to fill in the Solution File Path field with the name of your .sln, it’s relative to your project structure (if it’s in the root, enter only the name of your solution file. Fill the rest of the field if you are using NUnit or MSTest.

Last step! Go to the Version Control Settings tab and click Create and attach new VCS root. Give it a name and choose the version control system (VCS) you want to use. Fill in the required field.

Save, and you’re done!

This is the most basic setup you can have. Of course, there is a lot of other things to configure to your specific needs. You can even have integration inside Visual Studio or Eclipse. As I said before the only downside I found is the lack of support for MbUnit, but I will work something to bypass that.

I may do another post going more in depth if I have time. Or maybe a screencast, that would be a lot of fun. If you’re interested, just leave a comment and I will consider it.

Sometimes, you come across real treasure! This is one of them, printed and with me for a long time.

I have just finished reading the “Foundations of Programming” series by Karl Seguin. This is a “Must Read”. It’s a really great series that cover all aspect of building an application. I can’t recommend it enough!

Here is a link to the PDF file which has all seven posts.

Let’s not go on too much complicated stuff. This is an easy step-by-step to add a coverage report to your automated builds.

Andrew Stopford’s Weblog

(Index of the whole series)

Before we go on, you need to now what is “Continuous Integration”. This is a long topic and you should probably read Martin Fowler’s article on Continuous Integration.

Now that we have determined the structure of the project and put the source in the repository, we need to set up the continuous integration server. The tool we will use for that is CruiseControl.NET. The guys behind it have really done a great job. We need first to define “what we want”.

What we want :

1. Checking for modifications in the source repository.
2. Get the latest version if modifications are detected.
3. Build the project.
4. Run the test suite.
5. Reporting any successes of failures.

We also want to “fail fast”. This means that at any step, if something is wrong, we won’t go further and report it.

So here is the step by step approach :

1. Downloading and Installing CruiseControl.NET

Download CruiseControl.NET here. I’m using the version 1.3. Then double-click on the executable and follow each step. Normally, I’m leaving everything checked except the help files and examples.

You will be asked if you want to use CC.NET server as a Windows Service. Basically, if you want CC.NET to always run (and in my opinion, it should), my advice is to run it as a service. But some scenario may require that you need to run it only once in while. In that case you only need to execute ccnet.exe to start the server. Next, it ask you if you want to create a virtual directory in IIS for the Web Dashboard. I’m leaving it checked as I want to use CC.NET as a service.

2. Setting a basic project in ccnet.config

Find your ccnet.config (in your ccnetinstallationfolder\server). Every step you want to be executed will be defined here. This require some basic knowledge in xml.

 

 

<!--<ccnetconfig><configurationVersion>1.3</configurationVersion></ccnetconfig>-->

<cruisecontrol>

  <project name="LogItAll">

  </project>

</cruisecontrol>

I’m usually starting with an empty configuration file. The <cruisecontrol> tag is the root and you have one <project> tag per project.

 

 

<cruisecontrol>

    <project name="LogItAll">

        <workingDirectory>c:\dev\logitall</workingDirectory>

        <artifactDirectory>c:\dev\logitall\artifact</artifactDirectory>

        <category>Personal application</category>

        <modificationDelaySeconds>10</modificationDelaySeconds>

        <triggers>

          <intervalTrigger name="continuous" seconds="30"/>

        </triggers>

        <labeller type="defaultlabeller">

          <prefix>0.0.</prefix>

        </labeller>

   </project>

</cruisecontrol>

The <workingDirectory> will serve as the root for all our operations. Instead of specifying the full path, we will use the relative path. Example : \tools\nant\nant.exe instead of C:\dev\LogItAll\tools\nant\nant.exe.

The <artifactDirectory> is where every logs (builds, unit tests) is stored. This tag is not needed.

The <category> is simply in which category you want the project to be. This tag is also not needed.

The <modificationDelaySeconds> is the interval of time in which no modification must be done to the source to continue executing all remaining tasks.

We then have the triggers bloc. This block contains all the reasons that we want to perform a build. I recommend using the documentation of CC.NET to learn more. The <intervalTrigger> is, as the name imply, a trigger that will launch the build process every 30 seconds if any modifications is done to the source.

Finally we have the <labeller> which will give a label to the project. There is a lot of different labelers to use. In my case, I’m going with the default and starting the build number at 0.0.*.

3. Checking if any modifications is done to the source and getting the latest version.

The sourcecontrol tag is need to know if the source have changed. This will also get the latest version of the project.

 

 

<cruisecontrol>

    <project name="LogItAll">

   ...

    <sourcecontrol type="svn">

      <trunkUrl>svn://localhost/repos/LogItAll</trunkUrl>

      <workingDirectory>c:\dev\logitall</workingDirectory>

    </sourcecontrol>

    ...

    </project>

</cruisecontrol>

I can’t go on all the details because each source control has it’s own set of properties and features.

A lot of source control providers are supported (SourceSafe,CVS, etc..).

4. Build the project and run the unit tests suite.

First, we need a <tasks> section. This section should contains all action you want to happen in order. Several tasks are available.

A build file will help tremendously. Since we already have the build process in our own file for development, why shouldn’t we use it to build the application on the CI server. Instead of using an MSBuild task and modifying two files each time we change something in our build process, we should use it. You can use the nant task to run our build file.

 

 

<cruisecontrol>

    <project name="LogItAll">

    ...

    <tasks>

      <nant>

        <executable>tools\nant\nant.exe</executable>

        <buildFile>logitall.build</buildFile>

        <targetList>

          <target>test</target>

        </targetList>

      </nant>

    </tasks>

    ...

    </project>

</cruisecontrol>

5. Integrating the results.

Every log files you want to see in the Web Dashboard need to be merged. To do that you need to add the File Merge Task of the publisher task.

 

 

<cruisecontrol>

    <project name="LogItAll">

    ...

    <publishers>

      <merge>

         <files>

            <file>Logs\*.xml</file>

         </files>

      </merge>

      <xmllogger/>

    </publishers>

    </project>

</cruisecontrol>

This will embed the content of all the xml files in the logs folder in an xml file that the Web Dashboard will use to render it’s content. It’s really important that you add the <xmllogger>. It is required for the Web Dashboard to function properly.

If you are like me and you are using MbUnit as a test tool, you will need to perform some additional step to integrate your results files into the Web Dashboard. The solution is described in the Andrew Stopford’s Weblog. If you don’t see the report after that, verify that MbUnit genarate an xml file instead of an html file.

6. The Web Dashboard

The Web Dashboard is the easiest way to see every test results, builds logs, coverage statistics, etc…

You can access it via the http://nameofyourserver/ccnet.

7. CCTray

CCTray is a little application that helps you monitor your build. Simply access you Web Dashboard, and it the left menu, there is an option to download CCTray.

Then you need to add the projects you want to monitor. You do that first by entering the name of the server and then selecting the projects you want. I’m usually using the “Connect directly using .NET remoting.

Keep in mind that it is a basic tutorial and I intend to develop a little more in the following months. In the meanwhile, I will appreciate any comments, suggestion or ideas.

(Put me in your feed reader ! :P)

(Index of the whole series)

I have completely forgotten to show you the basic folder hierarchy of my solution. I invite you to try once to make a completely different folder hierarchy instead of the one Visual Studio suggest. Not that Visual Studio is a bad tool for this, not at all. I have learned that letting a tool do the folder management can lead on to unnecessarily complexity. Let me explain myself. There is an adage that say you should program into a language instead of programming in a language. Make Visual Studio work with your layout instead of using the default. I find interesting what you can learn when you organize yourself the layout of the solution.

Anyway, let’s see my folder structure :

The build folder is where the compiled application will reside. When doing automated testing I will use this version.

The config folder is where all the configuration files will be. I’ll probably get rid of it real soon as I have probably found a way that work better for me.

The lib folder contains library that are necessary for the project to be executed correctly.

The sql folder will contains all the sql script. This is also considered to be removed.

The src folder is composed of the app folder and the test folder. Each one contains a subset of all the projects (tests projects in the test folder and application in the app folder).

The tools folder contains any tools that are not necessary to execute the solution but are needed for the development.

It’s basically all I need for now to begin iterating on my application (using User Stories of course). I must mention that I doing this in an iterative way and a lot of things are subject to change. Any comments are greatly appreciated and will be read and considered.

I’m also considering to put all source file into Google Code. Stay tuned!

I am a long time reader of the CodeBetter.com blogs and usually read all their posts. But last year, I missed one that I consider a gem. If you ever struggled with building a continuous integration with CruiseControl.Net, you will find that screencast very instructive. Excellent job Jean-Paul S. Boodhoo’s!!

Automating Your Builds With NAnt - Part 8 (Enter CruiseControl)

I have completed configuring my first continuous integration server for an ASP.NET Web Application.

Here is the workflow:

1. Get the latest source from SourceSafe.
2. Compile of course. The first compilation is done with MSBuild.
3. Second compilation with devenv.exe (Visual Studio). For some reason, MSBuild does not compile deployment and Setup project.
4. Run unit test with MSTest.
5. Run Simian to detect code duplication.
6. Delete previous log file.
7. Deploy the web application.
8. Copy Web.Config to the web application folder.
9. Create database and execute all the database scripts.
10. Start Selenium Remote Control and execute all functional tests.

The tools used are:

• CruiseControl.NET
• sqlcmd
• NAnt
• Visual Studio 2005
• Selenium Remote Control
• MSBuild
• MSTest
• Simian

I have been through a lot of problem during the setup, but how fascinating it was! I was in constant learning.