Subversion + Ant Release Scripts

I’m not sure where this script fits into ‘The Joel Test’, but in the interest of automating the process of releasing a build in Subversion, I had the new guy (hey Pete!) spend his first couple days writing a script that:

  1. copies the trunk to the named branch (ie: /myproject/trunk –> /branches/1.10)
  2. copies the ‘latest’ tag to a tag called ‘rollback’
  3. copies the newly created branch to /tags/latest

The end result is that when we decide to do a release to the production environment, we can simply run the script (download the plain text) which copies the Subversion trunk (the main line of development for those unfamiliar with Subversion) to a tag we called ‘latest’ and also to a branch which matches the version number of the release. We point our production servers to /$project/tags/latest and our development servers (which we setup to run nightly builds) to /$project/trunk.

And just so we know that everything is running smoothly, he modified the Ant deployment script so that it sends an email upon completion indicating success or failure along with the output from the build. The email part I thought was going to be relatively simple (ie: use the mail task), but I wasn’t so sure about the generated output. Turns out that you can use MailLogger feature to listen for and get the status of build events simply by appending a logger flag to the invocation of ant:

ant -logger

and then by setting the appropriate properties in your build file.

Database Meaning

Rafe Colburn pointed to a blog posting by David Heinemeier Hansson where he that you should keep your business logic in your business layer rather than in your database which then lead to a blog post by Martin Fowler entitled Database Styles. Martin says he has only one principal point but he I think he made two good points. First (as he mentioned), there are generally two styles of databases: application databases (a database controlled and accessed by a single application) and integration databases (which acts as a data store for multiple applications) and that when you enter a discussion about THE ‘database’, you need to make it clear which type of database you’re talking about. His second point is that SOA (I’m not a fan of the acronym, but I like the implementations) can make and maybe should make integration databases unnecessary. Instead of having multiple applications interop through a common datastore (which is really nothing more than a gigantic global variable isn’t it?), each application maintains it’s own application database and communicates through a service interface like SOAP, REST, JMS, etc.

Rafe went on to make a good point as well (or maybe just a point that I agree with). He said that the one exception he makes to the rule of logic in the business layer rather than the database is the use of constraints. A commenter summed it up nicely by saying that “… constraints are to your data what assertions and tests are to your code.”