While a most of the hot-shot software companies have charged into source control management for the twenty-first century by using systems such as Git and Subversion, many of us “back-orifice” workers, whether we are a part of an IT staff supporting a legacy system, or are part of a development team that can’t seem toÂ make time for an upgrade, are stuck using antiquated source control systems like VSS or even Star Team. Thankfully, some of the other new-fangled tools which boost software quality, team productivity, and reduce development cycles, have kept us “grey suits” in their sprint planning. Either that, or they have made their platforms extensible enough so that other saps like me can write plugins to adapt to our situation.Â One of these systems is Sun’s fantastically simple-to-use continuous integration tool, written by Kohsuke Kawaguchi , known simply as “Hudson“.
There are blog posts a-plenty on installing and configuring Hudson…even on a (gasp!) Windows environment. Again, not my choice. But one that I have to live with if I expect our IT staff to back up and maintain my servers. When I went looking for more information on running Hudson with VSS, I came up empty.Â The point of this brief post is to go into some of the details and “Gotcha!”s that I came across while setting this up for our nightly integration build and test processes.
A quick glance at my setup will reveal Hudson being served up on the Winstone Web server (that comes bundled with Hudson) running on Microsoft Windows 2003. I have VSS insalled as a component of Visual Studio and so it lives under “C:\Program Files\Microsoft Visual Studio\VSS\win32″.Â This is important as most of your VSS work, whether being performed by Ant, Hudson,Â or from the command window will be performed by the command-line based “ss.exe”, and not the VSS client. I have Hudson running at the root of “C:\” and the various required versions of Java, ant and other tools and compilers installed in every other crack and crevice on this machine. Did I mention this is a “virtual” machine? Indeed, this machine is a guest VM on a VMWareÂ®Â ESXi server. So far, we have not had any major issues with this setup.
This VM isÂ currently building all of our applications . In a future blog entry, I will discuss our plans for virtualizing each of the build “slaves” that will eventually free up resources on this VM and allow us to perform both simultaneous builds and real-time integration testing. But for now, storage is at a premiumÂ since all of our products live in separate repositories. Each repository has to be checked out at the root level in order to do a build. This takes up lots of space and is a very inefficient way to handle source code…but VSS has limitations that we can’t seem to work around. Specifically, its weak merging and tagging capabilities render it useless for these purposes. It is because of this that the build jobs are forced to modify environment variables among other things as a precursor to any build being executed.
I also have the VSS plugin installed and configured to “talk” with our repositories. This plugin has proven to work very will for polling the repository and monitoring usage. It is important to note that this plugin does not handle “checkouts” or “gets” from VSS. It will, however, check for Ant files in the root of your repository. If you have Ant tasks using <vssget> to pull your source down, you simply call into that from a Hudson task and get your source. We don’t have these tasks written, so I “manually” call out to vss.exe directly from a Hudson command line script like this:
ss get $/Project -RQ
I will get to why I pass the -Q switch in a minute…although it doesn’t do exactly what I want. This seems to work as long as you are aware of the “gotchas”. These gotchas may or may not happen with an Ant task as well since Ant uses ss.exe under the covers. Now, on to the “Gotchas”:
Gotcha #1 – Environment
The first thing you need to check if you have a setup similar to mine is your environment variables. As you can see above,Â ss.exe depends on “SSDIR”. If you are doing multiple builds on a single machine, it will be necessary to modify this environment variable each time you do a checkout from a different repository. Hopefully, your development team doesn’t create new physical repositories when they “branch”. But ours does. The other biggie is simply to make sure “ss.exe” is in your system path (especially if you are building on a slave).Â It’s a minor detail, but got me once or twice.
Gotcha #2 – Checkout
VSS gets hung up during the build process ifÂ \workspace directory has read-only properties.Â The workaround is to use the windows “attrib” utility to set permissions on this directory. The biggest problem with this and some of the other gotchas is that there is no feedback to the Hudson console view. The build will just hang on “getting latest source from vss…”Â If you are not blowing away your workspace directory with each new build, you can set this permission manually and Windows should retain permissions on all subsequent newly checked out directories, files and sub-directories.
Gotcha # 3 – Quiet Checkout
Whenever you set up a new build job and do a vss checkout, you may get prompted to re-set your working directory.Â Again, there is no notification to the Hudson console that this is the problem. But if you go try to manually do a checkout using ss.exe from your \workspace directory, you will see the prompt. Once you set this (say “Yes”), the builds will not stop on this step again. Even still, I tried to find a “-quiet” parameter for ss.exe. There is, but it doesn’t seem to work. I still get prompted.
Gotcha # 4 – Multiple Confirmation Questions
This gotcha follows closely behind #3 because it got me even though I was aware of #3. In fact, sometimes when you change repositories, VSS will prompt you twice to confirm that you indeed want to change your working directory. I am not really sure why Microsoft thinks I can’t make up my mind about where I want my source to go, but they really want to make sure I have the safety off before pulling the trigger.
I don’t know if these few tips will help anyone else in the community of Hudson users. But I think there are more software shops than we would like to admit who are still using VSS. Hopefully, these tips will help get you past the common problems with using VSS with Hudson.