Agile Development Tools Server Part 1 - Subversion

Creating an agile development tools server is possibly the biggest time saver for a developer when beginning a startup. Frantically running a manual deployment process, hacking together code from five developers without version control or breaking code without running unit tests are common scenarios which can be eliminated via the proper use of agile tools, in particular an agile tools server.

This is Part #1 of a series of tutorials which will show you how to build a highly robust server that you can use for version control, project management, continuous integration and full stack monitoring. In the first part we will cover setting up a version control repository using the open source Subversion (SVN) agile tool on the Ubuntu Server 10.04 LTS operating system.

The first step is to obtain yourself a fresh Ubuntu LTS machine (virtual or physical!). If you are just trying out some agile development tools and wish to give SVN a go, I recommend following my other tutorial on setting up a web development environment with VirtualBox and stop when you reach "Configuring the Virtual Machine". Alternatively, you can start a micro server instance in Amazon EC2 with one of the Canonical AMIs. I outline the basics of how to do that in my other tutorial on Desktop Ubuntu in Amazon EC2 - The Right Way. You can follow everything up until "Desktop Installation".

We will set up the tools box up by installing the Apache2 webserver, using it to serve SVN across SSL so that we have a secure encrypted connection to our repository. This stops others sniffing our packets and stealing our prized code! In addition we will enforce user read/write privileges so that we can choose who can modify our codebase.

Let's begin by updating and upgrading our server so that it has the latest security updates. Log onto the server and type:

I generally install some "admin packages". These include my favourite text editor Emacs 2.3, htop (a much more usful version of top), screen (multiple terminals in one terminal!) and build-essential for all any compilation via source that may be required:

The next step is to install all of the packages that Subversion requires in order to run. We install Apache and SVN, then the Python Module for Apache and Python-Subversion which is used to communicate with your repository via Python, funnily enough!

We are now going to create a permanent location for your repository. I tend to create my repos outside of the home directory as I may need to change usernames at a later date. Let's put our repo in /var/lib/svn. To achieve this we run a subversion command, svnadmin, which populates the repo directory with all of the necessary configuration and storage files:

We need to make sure that Apache has access to this repo, so let's change the ownership recursively (-R) to the www-data user for the svn directory:

We now need to create a skeleton codebase to import into our new repository. You may already have a codebase in use that you wish to you add, in which case you should add the code underneath the /tmp/myproject/trunk directory below, otherwise follow the proceeding steps to create a new codebase:

The next step involves configuring Apache to make use of the encryption provided by a Secure Socket Layer (SSL). SSL makes use of public-private key encryption. The "plaintext" is encrypted via the public key and decrypted via the private key. In order to employ SSL with Apache it is necessary to use a signed certificate which usually involves authenticating our identity against a third party. In this instance we will use a self-signed certificate as there is no need to prove to third parties (i.e. website users) that we are, indeed, who we say we are. Let's install SSL:

Now we need to generate our keys and certificates. We are going to use the genrsa command to create an RSA-based DES3 key (of 1024-bit strength) for our Certificate Signing Request (CSR):

You will be prompted for a challenge password. It is convenient, but highly insecure, to leave this blank. I recommend you do not leave it blank.

Note: Upon rebooting the server once all of this installation is complete, apache2 will initialise and prompt you for this passphrase. On my VM I did not yet have keyboard access to the TTY and hence I was unable to enter it. The only way I could (immediately) find around this problem was to create an insecure key without a passphrase. I wasn't fussed as this was a test VM. On a live server I would have to spend longer thinking through the issue. Any suggestions would be greatly appreciated in the comments!

Now that we have created our key for our signing request, it is time to actually self-sign our certificate. We input our signing request and our key and output the SSL certificate file. Then we copy the files to Ubuntu's SSL directory. Finally, we enable the SSL Apache module with the shortcut a2enmod:

It's time to configure Apache to serve our SVN repository over SSL. We need to create a basic authentication htaccess password file so that any random Joe who points their web browser at https://svn.yourproject.com/ is not allowed to view your codebase. Run the htpasswd command to create a new user myuser. You will be prompted for a password:

In addition, we need to tell Apache to listen to port 443 (the default HTTP SSL port) so let's open up the virtual host configuration file and add in a NameVirtualHost for that port:

Add the following lines in the appropriate place:

Now we need to create the configuration for the SVN virtual host itself. I've called it svn-myproject but you are free to call it anything that does not clash with another virtual host. We're going enforce SSL encryption and basic auth. The listing below should be reasonably self-explanatory regarding your own server information:

Now add the following in the file, replacing the ServerAdmin and ServerName attributes as necessary:

Let's create the web root to stop Apache throwing a warning about non-existent directories:

Enable the site and reboot Apache:

You can test that your repository is working by visiting your repo (don't forget to prefix with HTTPS) in your browser with the IP/domain configured as for your virtual host configuration above. It is quite handy to be able to browse the structure over a web connection sometimes!

Currently this will give any user who passes the basic auth test full read/write access to your repository. To allow more fine-grained access, you can edit the /var/lib/svn/repo/conf/authz file and add usernames with read and write privileges ("r", "w" or "rw"). This is particularly useful if you are working in a team or wish to share your repo over the internet and only want to allow the masses read access.

In the next set of agile tools development server tutorials I will outline how to install Trac for project management, continuous integration and monitoring tools as well as off-site backup strategies.

I'd love to hear about other setups being used - perhaps Git or Bazaar with alternative project management tools. If there's anything you think I've left out, please let me know - I want the tutorial to be as accurate as possible!