Getting personal with SVN
Since we started using SubVersion (SVN) as a better way of managing code changes by the development team at work, I have started to use on my personal projects. Recently I configured a staging/testing server which is a mirror of the server configuration I run this website from, allowing me to test changes and developments to websites without the risk of downtime to this website.
To get it all setup and running has been pretty flawless, the main hindrance is the Wordpress database and it only working with the blog URL stored in the database. This means that to develop, test and make live I need to have three separate databases. A bit of a nuisance having to populate the development and testing databases with sample data, and the need to change the database connection strings.
In addition to using SVN to manage the code for my developments, I have been using Springloops to deploy revisions of the code to the staging server. Due to the basic account that I have setup I am only able to deploy to one server, otherwise I would also have the production server configured to deploy to. The integration with SVN is seamless and the deployment process reduces the risk of human error that can be found through FTP uploads, and you are also able to deploy earlier revisions of the code if necessary. Springloops is also capable of integrating with Basecamp, however I do not have the necessary Basecamp account to test out the full functionality of Springloops-Basecamp intergration.
I must admit that using SVN is a bit overkill for developing personal projects where there’s only one developer. The real power of the source code management tool is seen in multi-developer collaborative environments, however it is handy nonetheless to be able to revert to earlier versions of code.
Update: I have now got the Springloops-Basecamp integration working through enabling the Basecamp API within Basecamp, and I am able to check-off to-do list items with code commits through SVN. A further feature of Springloops is being able to review the to-do list items on the deployment servers as a matter of QA to verify whether or not the task has been completed.
This entry was posted
on
Thursday 29th November 2007 at
10:06 pm and is filed under
Development .
You can follow any responses to this entry through the
RSS 2.0 feed.
You can leave a response, or trackback from your own site.