I use PHPUnit and the DbUnit extension for my unit tests. Because I use InnoDB tables with foreign keys I cannot use an SQLite database or temporary tables to run my unittests on. So, I have set up a separate MySQL server to run all my unittests on. My PHPUnit bootstrap script simply generates a random database name and imports the schema so that DbUnit can use it.
The only downside is that after a while, you get a bunch of unused databases on the server. So, I have written a simple bash cronjob that deletes all databases from the server that have not been used for 30 days. This script uses the debian-sys-maint MySQL user that is automatically set up on all Debian systems for maintenance tasks.
In “Keeping SugarCRM under Subversion control” I showed you how I maintain the base SugarCRM in the face of changes to the core code. The setup described in that article allows me to make changes to the core code without running into (too much) trouble when SugarCRM ships a new version. It does have one downside: You cannot use Studio to make any changes. Instead, I keep all my customization work in a separate installable package, together with any custom modules I develop.
In this article I will show you how I develop my custom modules, how I keep them in Subversion and how they work together with the base SugarCRM from the previous article.
Updated on 2006-09-20 to add an exclude file and clear up some rsync confusion
I hate making backups by hand. It costs a lot of time and usually I have far better things to do. Luckily GNU/Linux comes with all the tools you need to backup your machines automatically and wide availability of broadband make it possible to have remote backups as well - to a friend's place for example.
This article will show you how to set up fast, fully automated local and remote backups for a small home network using standard GNU/Linux tools.