The easiest way to set it up is to get VisualSVN. I have written about it before, and it is a snap to use. You install it and follow the prompts, it really is that easy.

Next time- setting up continuous integration

The strange thing is that it is the same client who caused me the problems which started this. The history of deployment to this client is briefly this: First time we had to make sure that we were going to the right place, check connection strings etc etc. So it was a case of check and double check and that made it go a little slowly. In addition I had a missing dll on my laptop so I went back to work, fortunately close by, did a fresh checkin from Subversion onto the laptop, recompiled, and went back to the client. All up, deploying and running a few acceptance tests took a couple of hours. Far too long in my view.

The second time was a nightmare. There were a few changes requested by the users and one additional feature. There was also one feature (user story for the agilists) that I had misunderstood slightly. That meant a couple of hours work. But it emphasised the value in short iterations. The first iteration was four weeks. So, very quickly, a wrong understanding by me of the requirements is rectified. If I had been given the requirements for the full product and disappeared for three months that would have been a lot more time, and a lot more money, developing the wrong feature. Back to the deployment. The client asked for a zipped file which I sent to them. I had forgotten to change the database connection string, so it didn’t work. Fortunately it didn’t crash but brought up a nice message box with a re-assuring message that all was right in the world. But it wasn’t going to connect.

I changed the connection string and recompiled, rezipped, and re-emailed. I forget the next problem, or the next or the next. However, I sent the first zipped file on a Friday. They got the working version on Tuesday and I felt, and probably looked like a fool.

The third iteration was again on a Friday, perhaps a bad omen. I wasn’t risking sending a zipped file so I loaded everything onto the laptop and went to see the client. I was there for about half an hour – 25 mintues talking about the next project they want done, and 5 minutes deploying. The guy who did the deploying did his black magic about which I know nothing. Two screens, each with half a dozen open windows filled up with line after line of voodoo incantations, and suddenly it was deployed. He checked the new features and the changes. He checked a few old things and it all looked fine. I left feeling relieved, knowing that this was more good luck than good management.

I said in thelast article that I used Windows Server 2008 because I wanted to try it out. I nothing of servers and I had trouble getting the network working properly. After a few days of frustration I removed it and installed Vista because I have set up a Vista network previously. In any event it is really a peer to peer network that I am after, not a client-server network. So getting to know Server 2008 is for another day.

Getting a few PCs to talk to each other is a piece of cake for a network person. Not for me In the old days when I worked for an employer and had a network problem I would ring up a network guy (it was always a guy) who would come up from the bowels of the building, or whereever they lived. He would ask a few questions that I couldn’t understand. I would shrug my shoulders so he would ring up another network guy. They would talk in acronyms for a while and suddenly I was back on the network. I don’t know how it works.

Eventually I got the network setup. The computers could talk to each other and I could login to SqlServer remotely. It was time to continue.

What I want is to be able, at the press of a button, to produce a release version of my program ready to be deployed onto the client machine. That sounds reasonable, doesn’t it?

So what tools do we need? first is VisualSVN. I have written about this before. It isn’t free, it costs $US49.00 but it is worth every penny. It installs Subversion and works a treat.

I also managed to get an old, not too old, PC set up. It needed a hard drive, but I had a spare one of those lying around. If you have been developing for any length of time you tend to accumulate bits and pieces that can sometimes come in handy. The PC needs a memory upgrade, but that is not an issue – memory is pretty cheap.

You don’t need a separate PC, but I thought it worthwhile, performance and all that.

First you have to set up the PC. I installed Windows Server 2008. You don’t need server software, XP or Vista will do. You can even install Linux and Mono. So long as you can compile your C#, or VB.Net code you are OK. But I used Windows Server 2008 because I had it and I wanted to try it out.

There are a couple of things that need to be installed. First you need the CLR of the version you are developing on. These days there is no point in not installing 3.5, even if you aren’t using its features yet. By the end of the year you will probably want to install 4.0. But you will certainly want at least version 3.0. However, that doesn’t mean that you want to install Visual Studio, just the framework, because all you really need is the compiler.

You will also need to install VisualSVN Server. This will setup the Subversion Repository on your server. You client, or development PC will connect to the Build Server and hence the Subversion Repository. More on setting up the Subversion Repository next time.

The next piece of software that you want is Continuous Integration software. There are a few of these around. I suppose the most common has beenCruiseControl. I looked at this a year or so ago and it seemed fairly complex to set up. At that time I didn’t think that it was going to be of any great benefit to me so I didn’t pursue it. But a few months ago I came across TeamCity. It was love at first site. It is incredibly easy to set up and we will look at that after we have examined Subversion more closely.

Finally, I installedVMware Workstation to help me create virtual machines. You can use something like VirtualPC but I think VMware is a better product, but you have to pay for it. We will look at VMware and what it brings to the build process in a later post.

Really finally, there are some other things I installed which aren’t necessary for the build proces but are useful to have. I will describe these later on.

That’s it for. Next time – VisualSVN and Subversion.

The crash wasn’t hard. I caught the exception and showed a message box saying something like “There is a database error. Try again and if the problem persists then contact your system administrator.” They were happy with that.

The additonal features were fairly straightforward. They were all to do with searching through a collection. In days gone by this probably would have meant using regular expressions. But not any more. Throw in a bit of LINQ and voila, feature done, more or less.

I loaded the changes onto my laptop and took it out to the client. They agreed that it was all good and I left the files with their systems guys to load up. A little later in the day I received an email saying that it didn’t work. Nothing worked. Every screen, including the ones which previously worked fine and were all approved, now crashed. This was impossible.

The application worked on my laptop, they had seen it work. It worked on my development machine. My unit tests passed. Everything worked. Except where it mattered; it didn’t work on the client’s system.

The one response to bugs that every developer hates to give is – but it works on my machine. The client doesn’t care about your machine. If you turn it on and it catches fire and burns your house down, the client doesn’t care. The client only cares that your application doesn’t work on his machine.

So we developers don’t say that it works on my machine. Instead we say that we cannot reproduce the bug. That sounds much better. And if we have bug tracking software we probably even have a category – Cannot Reproduce. But it means the same thing.

Now, we all have clients who will ring up after you have spent three days chasing down an elusive bug and say, “I forgot to mention, we have had a blackout for the past three days. Will that stop your program from working?” Or something equally inane. But my client wasn’t like that. They had technical people there who are pretty smart and they also tried to find the cause of the bug.

After a few days we found the problem. Naturally it was my fault. The details aren’t important but it boils down to the fact that my development machine is not the same as their production machine. I have dlls installed that they don’t. It is easy to forget to copy them all across. It is easy to leave the database connection string unchanged. It is easy to forget to change the configuration from debug to release.

In other words it is easy to forget to do a whole heap of things. That’s why we use computers, they can remember stuff that we don’t.

Next time we will look at what we need to ensure that we are set up properly so that we don’t look like an idiot in front of the client.