Wrapping Up: A Linux Script For The End Of The Day
Here's another one of my little Linux admin scripts for all you Drupal developers out there. It's a Linux shell script requiring Drush, MySQL and Subversion, but could be easily modified to work with other databases and repositories and should work fine on a Mac, I think.
You'll need to modify it to your specific paths anyway, as this is set up for our standard working environment. It assumes the database dump name is always the same as the workspace project directory name (in our case this is true), the workspace is in the Linux user's home directory and each project contains a trunk/db directory for database snapshots and a trunk/www directory for the actual application.
Here's what it does:
- Clears Drupal's cache
- Deletes the old database dump
- Dumps and bzip2s the database in to a pre-determined location in our workspace
- Commits the new database dump
- Updates the application (to catch any updates others might have done today)
- Commits any changes to updated files/commits all added files
So when it's run, we have a database dump in synch with the code in version control. Always! I automated this because people (including myself) get lazy and can't be bothered to create the database snapshot with the code commit. This does it for them (and me) so it always happens. Yay!
Here's the code:
if [ $1 = "--help" ];
then
echo "
#########
# USAGE #
#########
Syntax for running this script is:
./end_of_day.sh projectdir databasehost databasename
projectdir - string, project directory in Eclipse workspace
databasehost - string, hostname or IP for database server (usually localhost)
databasename - string, name of database
." &
else
# TODO: we should really use drush to mark certain tables as excluded
echo "Clearing the Drupal cache to make the db dump smaller ..."
cd ~/workspace/$1/trunk/www
drush cache clear
echo "Updating application db directory at ~/workspace/$1/trunk/db ..."
svn up ~/workspace/$1/trunk/db
echo "Deleting old db dump from repository ..."
svn delete ~/workspace/$1/trunk/db/$1.sql.bz2
svn commit ~/workspace/$1/trunk/db/ -m "AUTO: deleting old database dump"
echo "Creating new db dump of $3 from $2 ..."
if [ $2 = 'localhost' ];
then
mysqldump -u root $3 | bzip2 > ~/workspace/$1/trunk/db/$1.sql.bz2
else
mysqldump -u root -h $2 $3 | bzip2 > ~/workspace/$1/trunk/db/$1.sql.bz2
fi
echo "Adding new db dump to repository ..."
svn add ~/workspace/$1/trunk/db/$1.sql.bz2
svn commit ~/workspace/$1/trunk/db/ -m "AUTO: adding new database dump"
echo "Updating application www directory at ~/workspace/$1/trunk/www ..."
svn up ~/workspace/$1/trunk/www
echo "Committing any added code changes to repository ..."
svn commit ~/workspace/$1/trunk/www/ -m "AUTO: committing code changes at end of day"
echo "Done!"
fiNote the "TODO" task there.
Thank you, nice script. I
Thank you, nice script. I translated it to Russian and put on my home page. you do not mind? ;)
Not at all
Glad you like, enjoy it in Russian! =)
Be sure to check out the new
Be sure to check out the new features in drush branch 3.
supports generating db dumps excluding a customized set of tables (which will be excluded alltogether or dumped as structure only)
drush sql-dump --help
see example.drushrc.php for params
Also see this great write-up about drush working with local and remote drupal installs : http://drupal.org/node/670460
Commit message
I can see the benefits of automatically having a sql dump committed in subversion, but without meaningful commit messages you lose a big advantage of using a vcs.
Update
Untested, but would this make you feel better?
if [ $1 = "--help" ];
then
echo "
#########
# USAGE #
#########
Syntax for running this script is:
./end_of_day.sh projectdir databasehost databasename commitmsg
projectdir - string, project directory in Eclipse workspace
databasehost - string, hostname or IP for database server (usually localhost)
databasename - string, name of database
commitmsg - string, optional commit message for the code
." &
else
# TODO: we should really use drush to mark certain tables as excluded
echo "Clearing the Drupal cache to make the db dump smaller ..."
cd ~/workspace/$1/trunk/www
drush cache clear
echo "Updating application db directory at ~/workspace/$1/trunk/db ..."
svn up ~/workspace/$1/trunk/db
echo "Deleting old db dump from repository ..."
svn delete ~/workspace/$1/trunk/db/$1.sql.bz2
svn commit ~/workspace/$1/trunk/db/ -m "AUTO: deleting old database dump"
echo "Creating new db dump of $3 from $2 ..."
if [ $2 = 'localhost' ];
then
mysqldump -u root $3 | bzip2 > ~/workspace/$1/trunk/db/$1.sql.bz2
else
mysqldump -u root -h $2 $3 | bzip2 > ~/workspace/$1/trunk/db/$1.sql.bz2
fi
echo "Adding new db dump to repository ..."
svn add ~/workspace/$1/trunk/db/$1.sql.bz2
svn commit ~/workspace/$1/trunk/db/ -m "AUTO: adding new database dump"
echo "Updating application www directory at ~/workspace/$1/trunk/www ..."
svn up ~/workspace/$1/trunk/www
if [ $4 = ''];
then
echo "Committing any added code changes to repository ..."
svn commit ~/workspace/$1/trunk/www/ -m "AUTO: committing code changes at end of day"
else
echo "Committing any added code changes to repository with message '$4' ..."
svn commit ~/workspace/$1/trunk/www/ -m "$4"
fi
echo "Done!"
fi
Define meaningful
Sure, this is only the "end of day" script that ensures a DB dump is filed with the code. Other commits through the day should still occur, and be appropriately messaged. This script is only intended to "tidy up".
However, people often talk about "meaningful commit messages" and I'm yet to find someone tell me what that means! I find the list of files changed perfectly "meaningful" on their own.
Though maybe that's because I need to define some sort of structure to the commit messages. Problem is that's more red tape and training for new people and, to be honest, I never have any trouble finding what I want as things stand. I might add the ability to pipe in a commit message for the code too though. Not a bad idea. =)
Storing binary dumps in repo
Nice article and script! This sort of automation is always useful to have as another option in one's Drupal repertoire!
I know versioning the database will be the subject of a little bit of contention amongst Drupal developers in general. One thing I notice is that you are compressing the database before committing it to version control, but would this work better as plain text? The initial commit would be much larger, because it's an uncompressed text file, but subsequent commits will only record the changes to the database, so ought to be very small.
Also, you would then be able to diff revisions of the database to see exactly what's changed!
Good one
Great point about not zipping the databases. But I really need to make sure I'm excluding cache* and watchdog tables first.
Use backup_migrate module to
Use backup_migrate module to dump the DB: that automatically knows to skip cache tables.
I don't think it has drush integration yet, but that's surely not hard to patch!
Backup and migrate has very
Backup and migrate has very great drush integration!
drush bam backup and you are set!
Post new comment