Using QuickBuild for building and deploying apps is fun! I’ve got 3 of my apps into QB now, and their build and deployment is almost completely automated. I’m getting closer and closer to the Holy Grail of release management – the “magic button”. You know, that button you push that just automagically a) pulls your code from the repo, b) builds and/or copies all dependent jars to the app local folder, c) builds (compiles and packages into a .war) the app and d) (the grand finale) automatically deploys the application to our Weblogic farm.
One thing we had to do (or rather, get the engineers to do!) was standardize on how we use environment-specific variables. Obviously, for DB connections your best bet is to always use datasources whenever you can. Then your apps just need to refer to those, rather than using database servername, db name, user, password, all that junk. Not only does this streamline the migration from dev to qa to prod, but it also abstracts your database connection info, which is nice for several reasons (not the least of which is security).
But what about other variables? What if your log location is different in dev vs prod? Or what if you want to send error e-mails to a different address from qa vs prod? You need to do some kind of variable substitution at build time. Enter the .tmpl file.
Require (or ask, or beg, or bribe) your engineers to keep all of these “configurable” values in one file – typically an ApplicationContext.xml or something that looks like it. Then, have them put the values for these variables in a properties file somewhere (app.properties or whatever). The last step is to actually use a .tmpl file, and dynamically generate that .xml file using this instead. If no values are passed through to the file from ANT or QuickBuild, then the app will just use the properties specified in the properties file. But if you do want to pass them through at build time, all you need to do is create a variable for that config in QB (or ANT, if you’re not using QB yet!), and viola! – you’ve got the right stuff where it needs to be.
Release Management 