Something Pithy - cm tag

even more FitNesse GoodNesse

Fri, 14 Apr 2006 02:40:29 GMT

We ran into a little hitch not too long ago with our fitnesse tests. We are now up to 4 different suites of fitnesse tests, one for each of 4 different solutions. The solution have dependencies among themsleves. We had been doing work on one solution, doing our TDD red-green-refactor and our fitnesse equivalent. Moving along nicely. And then cam a day and we had to do some work on a different solution that we hadn't made any changes to in a few weeks. Made some simple changes, checked them in, and (as described in a few previous posts) our CC.net build kicked off, followed by the fitnesse tests for that project. What surprised us was that the fitnesse tests broke. In a strange place. Turns out we had an integration breakage. Changes to project B had caused the fitnesse tests in project A to fail, and we hadn't noticed since those tests hadn't been run in a couple of weeks. So after we got the tests passing, we resolved to set up a system to keep us from going that long with breakages we didn't know about.

I set up a new project in my ccnet.config file like this:

<project name="nightly_fitnesse">
      <webURL>http://buildserver/ccnet/Controller.aspx?_action_ViewProjectReport=true&amp;server=buildserver&amp;project=nightly_fitnesse</webURL>      <triggers>
        <scheduleTrigger time="23:30" buildCondition="ForceBuild" />
      </triggers>
      <sourcecontrol type="svn">
        <executable>c:program filessubversionbinsvn.exe</executable>
        <trunkUrl>svn://codeserver/fitnesse/trunk/</trunkUrl>
        <tagBaseUrl>svn://codeserver/fitnesse/tags/</tagBaseUrl>
        <workingDirectory>d:workfitnesse-trunk</workingDirectory>
        <tagOnSuccess>false</tagOnSuccess>
        <autoGetSource>true</autoGetSource>
        <username>cruisecontrol.net</username>
        <password>ccnetpassword</password>
      </sourcecontrol>
      <tasks>
        <nant>
          <executable>D:workdependencies-trunkexternalnantNAnt.exe</executable>
          <baseDirectory>d:workfitnesse-trunk</baseDirectory>
          <buildFile>AustinNightlyFitnesse.build</buildFile>
          <targetList>
            <target>fit</target>
          </targetList>
          <!-- this build timeout is fairly long, since these tests can get long.  -->
          <buildTimeoutSeconds>1500</buildTimeoutSeconds>
        </nant>
      </tasks>
      <publishers>
      <merge>
          <files>
             <file>D:workfitnesse-trunkresults*.xml</file>
          </files>
      </merge>
        <xmllogger />
      </publishers>
    </project>

We set up a new build file to run all 4 fitnesse suites - the parts that we call the 'regression' suite, which we expect to always pass. As you can see in the trigger block, it runs every night at 11:30, whether there have been any code changes or not. The build file is where I think the interesting bits are.

<?xml version="1.0" encoding="utf-8" ?>
  <project name="AustinNightlyFitnesse" default="fit" xmlns="http://nant.sf.net/release/0.85-rc3/nant.xsd">      <property name="fit.server" value="localhost" />
      <property name="fit.port" value="8080" />
      <property name="results.dir" value="results" />
  
      <target name="fit"	description="run fit tests">
        <property name="FitRegressionFailureSummary" value="0" />
        <delete dir="${results.dir}" failonerror="false" />
        <mkdir dir="${results.dir}" />
        <property name="fit.suite" value="GuideEngine.SuiteRegressionTests" />
        <property name="fitlibs.dir" value="c:fitnessedotnetGuideEngine" />
        <call target="runFitSuite" />
        <property name="fit.suite" value="LookupWeb.SuiteRegressionTests" />
        <property name="fitlibs.dir" value="c:fitnessedotnetLookupWeb" />
        <call target="runFitSuite" />
        <property name="fit.suite" value="FireFly.SuiteRegressionTests" />
        <property name="fitlibs.dir" value="c:fitnessedotnetFireFly" />
        <call target="runFitSuite" />
        <property name="fit.suite" value="ShareDoc.SuiteRegressionTests" />
        <property name="fitlibs.dir" value="c:fitnessedotnetShareDoc" />
        <call target="runFitSuite" />
        <fail message="${FitRegressionFailureSummary} Fitnesse Regression test(s) failed."
          if="${int::parse(property::get-value('FitRegressionFailureSummary')) != 0}" />
      </target>
      <target name="runFitSuite" >
        <!-- same basic steps, but these must all pass, or the build fails -->
        <property name="fit.testrunner" value="${fitlibs.dir}TestRunner.exe" />
        <echo message="running fit regression tests at http://${fit.server}:${fit.port}/${fit.suite} using ${fit.testrunner}" />
        <exec program="${fit.testrunner}"
              commandline="-results ${results.dir}Fit-${fit.suite}.html ${fit.server} ${fit.port} ${fit.suite}" 
              failonerror="false" resultproperty="FitRegressionResult" />
        <!-- now transform those results from html to xml, and then fail if there were any errors. Fitnesse helpfully returns that as a number. -->
        <exec program="java.exe" 
              commandline="-cp binfitnessefitnesse.jar fitnesse.runner.FormattingOption ${results.dir}Fit-${fit.suite}.html xml ${results.dir}Fit-${fit.suite}.xml ${fit.server} ${fit.port} ${fit.suite}" 
              failonerror="false"/>
        <property name="FitRegressionFailureSummary" 
                            value="${int::parse(property::get-value('FitRegressionFailureSummary')) + int::parse(property::get-value('FitRegressionResult'))}" />
        <echo message="${FitRegressionResult} Fitnesse Regression test(s) in ${fit.suite} failed." />
        <echo message="So far, a total of ${FitRegressionFailureSummary} Fitnesse Regression test(s) failed." />
      </target>
  </project>

Since properties in nAnt are mutable, it makes it pretty easy to do paramaterized targets. The strangest bit about this build file is how it adds up the number of faiures. Fitnesse TestRunner is nice enough to return an integer that indicates the number of failures and exceptions. When we exec the TestRunner, we set failonerror to false, and collect the result into a property. As mentioned before, we use the java tools to format the XML output into html. Then, we do a little nAnt expression voodoo to add up all the failures, so that failing one suite doesn't prevent the other suites from running. It is only at the very end of the 'fit' target that we fail with a message if there were any failures in any of the suites. Since we already have the fitnesse-details.xsl stylesheet in place, we can then see what the problems were right in our CC.Net dashboard.

Pretty cool.

Derek Cicerone Installing...: heat.exe - making setup easier

Wed, 05 Apr 2006 21:33:08 GMT

Ran across a cool new tool today! If you are releasing your software on Windows using MSI files, you really ought to know about WiX. And this looks like a most excellent tool to get you started in that direction. Derek Cicerone Installing...: heat.exe - making setup easier

Installing Subversion Server on Windows

Mon, 27 Feb 2006 22:39:03 GMT

An article in which I describe why you might want to set up a subversion server, and how to go about doing that on a Windows machine.

Why should I set up a subversion server anyway?

See the subversionary website for lots of details on why you might want to use subversion. Once you get through that, come on back here to find out how.

How to set up a Subversion server on Windows

Part 1 - installing the program and creating a repository

Install the subversion program - download from http://subversion.tigris.org/
start a command prompt
type svnadmin create [directory location] where directory location is something like d:\svn\projectname or just d:\projectname. Depends how you want to set things up. I tend to prefer setting up like d:\svn\projectname, and if you need multiple projects, each goes in its own repository. That also makes it easy to run the svnservice (described below) and just point it at d:\svn

Here is an example of doing that.
svnadmin create --fs-type fsfs e:\svn\<projectname>
I tend to use the fsfs filesystem type. Your other option is to use the BDB (Berkely Database) type. When Subversion was first released, BDB was the preferred type. Now, they are reccomending fsfs as the preferred type. If you want to read more on that, see this article comparing fsfs to BDB.

You should now see a directory structure like

e:\svn\projectname\conf\
                  \dav\
                  \db\
                  \hooks\
                  \locks\
                  \format
                  \README.txt

If you want to learn more about those directories and their contents, see the subversion book, chapter 5.

Part 2 - configuring the server

To provide access to your repository from another machine, you have to set up some sort of server 'daemon'. One of the cool things about subversion is that is supports several different access methods. They can be used singly, or you can use multiple methods at the same time. The easiest to set up is the built-in svnserve daemon, so I will describe that here. If you want to read more on this topic, see the subversion book, chapter 6.

To configure svnserve, you need to edit conf\svnserve.conf You can pretty much just un-comment the lines that have single # at the beginning, and then change the 'realm' to something better. Here is a stripped-down sample, with ALL the comments removed.
```
[general]
anon-access = read
auth-access = write
password-db = passwd.txt
realm = ProjectName Subversion
```

The anon-access line says that anybody who knows the URI of the server will be able to read from it - change this to none if you want to keep it private.
The auth-access line says that people who enter a correct username and password can commit (write) to the repository.
The password-db line gives the name of a file, relative to this svnserve.conf file, where passwords are kept. Note that only someone with access to the subversion server will be able to edit this file, and whoever has that access has the ability to see and change anyone's password. There is currently no existing way to allow users to change their passwords themselves if you are using the svnserve access method. If you do need something better, look into Apache-based web access.
The realm line is a human-readable name of a 'security realm'. It also provides a way for multiple repositories to share a single password file.

in the conf directory, create passwd.txt (or whatever you named the password-db in the svnserve.conf)
passwd.txt should look something like this:
```
[users]
joe.developer=SomeSuperSecretPassword
steve.donie=SomeOtherSecretPassword
```
If you use the person's NT login name as the username, it will make sending email as described below much easier. Depending on how your NT login names are configured, it should also be easier to interpret who made what changes if you ever look at the history of a file.
If you want email notifications sent out whenever someone commits (you should - it really enhances communication), do this:

install Perl from ActiveState. I used ActivePerl-5.8.6.811
Get copies of these files and copy them to your hooks directory:
```
commit-email-win.pl
emails.lst
post-commit.bat
```
I originally found these files in the subversion-users email list. You can also go straight to the email that has the files by following this link. The files are also available in this zip archive.
edit commit-email-win.pl to tell it where the svnlook program is, where the emails.lst file is, where a temp directory is, the name of the mailserver, and a default from prefix.
edit post-commit.bat to say where perl is, where the commit-email-win.pl script is, where to keep temp files, and the domain that emails come from.
edit emails.lst to have a list of email addresses to send to, one per line. One thing we do at my company is I have a little batch file MakeEmailsLst.bat that will create the emails.lst file for you based on the list of people in the passwd.txt file. This is a Very Good Thing - it is my opinion that if you have the privlege of comitting, you also have the responsibility of keeping up with changes to the project.

If you want to prevent people from checking in with empty log messages (also a Very Good Thing), take this bit of batch file:

@echo off

setlocal
set REPOS=%1
set TXN=%2

rem check for an empty log message
svnlook log "%REPOS%" -t "%TXN%" | findstr "." > nul
if %errorlevel% gtr 0 goto err
exit 0

:err
echo You must provide a log message. 1>&2
exit 1

and save it as pre-commit.bat in project's hooks directory.

Part 3 - Making the svnserve process into a Windows Service

You will probably want the svnserve server to run all the time, and the best way to do that is to make it a Windows service. No problem: Just download the svnserve service wrapper (a zip file) from here: http://dark.clansoft.dk/~mbn/svnservice/, and then unzip svnservice.exe to the subversion\bin directory (whereever you installed the original subversion program, back in part 1). Then install the service like this:

svnservice -install -d -r d:\svn

Part 4 - Checking your work

At this point, you should be able to go to a client machine, and use any of several SVN clients to access it. I use three different clients interchangeably, depending on what I am doing at the time. They all work together pretty seamlessly.

TortoiseSVN is great on Windows - it is a Windows shell extension that adds subversion commands to the right-click menu anywhere in explorer.
The command line client (which you get when running the subversion installer on your client, just like in step 1 above) is a great option to have around. Its command set closely mirrors that of CVS, so if you're familiar with that, the transition is pretty smooth.
AnkhSVN is a plugin for Microsoft Developer Studio that integrates very well - you can do nearly anything you need to right in the IDE. It also does things like automatically add new files to subversion when you add them in your project.

The first thing you will want to do in your new repository is set it using the 'standard' top level; directories. Typical SVN repositories have three directories named trunk, tags, and branches. Here is how to do that using the command line.

C:\work>svn co svn://servername/myProject c:\work\myProject
Checked out revision 0.

C:\work>cd myProject

C:\work\myProject>md trunk

C:\work\myProject>md tags

C:\work\myProject>md branches

C:\work\myProject>svn add trunk tags branches
A         trunk
A         tags
A         branches

C:\work\myProject>svn ci -m"creating initial repository structure"
Adding         branches
Adding         tags
Adding         trunk

Committed revision 1.

You could do the same thing with TortoiseSVN. I usually keep all my working copies in a directory called "work", so...

Open up Windows Explorer to c:\work, then right click and select SVN Checkout.... Enter the URI of your repository (svn://servername/myProject) and the directory to check it out to (c:\work\myProject). Click OK. You will get asked whether you want to create that directory, if it doesn't already exist, and then it will show you a progress dialog, showing success if you did everything right.
Change to your new directory and create the three new folders. Right click again and select TortoiseSVN -> Add.... A dialog with the three directories should pop up, and just press OK.
Finally, commit the changes by right clicking and selecting SVN Commit..., entering a log message, and pressing OK.

If you want to go into more depth, read the Subversion Book for more information on all of these topics.
I hope this has been helpful - please leave comments if not, or if there is anything I can do to clarify things!

Taking Continuous Integration to the next level

Wed, 28 Dec 2005 16:17:22 GMT

In which I describe a system that allows for build artifacts from one project to automatically propagate to dependent projects, extending Continuous Integration to a new level.