Build server changes

Related to the move of this website to the new server, I also had to make a few changes to the build server that I use to make the development releases. I’ll just start with an overview of the main changes, below I will explain in a little more detail how my build process works.

The main changes are:

  • I have moved from SVN to Git as a version control system, so the development releases won’t be identified by a revision number anymore, but with a Git commit ID. This means you will no longer have nicely increasing numbers, but each release will still have an unique identification number.
  • The previous development releases are no longer accessible on the site, only the last one is available. I  haven’t been able to figure out how to get this working in the new build system and also the amount of disk space on the new server probably wouldn’t be big enough.
  • The update notifications of old versions of the tool are broken now. That’s because the filetype (a file without extension) that I used to download the latest release date from is not allowed on the new server. So I had to change the filename and I have updated the current development release to check for this new name.

And now some more background information for those that are interested:

Old situation

For quite some time the daily development release is build automatically each night if there are changes. I did this to not have to manually publish a new release every time. And by using a build server, I also have an extra check if everything is correct in version control. Because it builds the applications from the sources in version control, so if I forget to commit a file I will notice that quicker.

Before all components of my build system were running on a small Linux based webserver I have at my house. So the SVN version control, the Jenkins CI build server and the web server where you can download the files were all running on the same machine.

You might have read Linux based server and wonder how I am building Windows tool on it? I have been using Mono for that all those years. So the tools you have been using have been build using the open source .NET alternative Mono.

But this small home server is not very powerfull (so building the whole tool takes like 15 minutes) and worse it is running on an older Linux distribution, which I can’t upgrade easily due to the specific hardware to make the server energy friendly. This old Linux distribution also meant I can’t install recent Mono versions and therefore I am stuck with .NET 3.5 or lower.

So now with the move to a new house in a few weeks, which would give downtime of time home server anyway, I thought it would be a good idea to change my build system a bit and get rid of some of the limitations.

New situation

Not really related to the build system, but I also decided to move to a different version control system, I’m now using Git instead of SVN. And I have my Git repository in the cloud as well, so that there is a backup outside of my house as well.

The Jenkins build server is now temporarily running on my development machine, so it is running on Windows instead of Linux now. This means I can upgrade to more recent .NET versions. Especially for scenProc the better support for parallel computing in .NET 4.0 could be useful.

The results of the build server are now uploaded to the webhost where the website is now hosted. You have probably already noticed it is no longer hosted at my house, since the site got a bit quicker now.

Once we have moved into our new house, I will probably setup the Jenkins build server on a spare PC, sot that it doesn’t have to run on my development machine anymore. But I don’t have the space (or time) at the moment to do so.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.