Deploying our app is hard.
We have to shut down the running app, modify the production databases, make sure that the links of the new app to our testing databases are switched to the production databases, bring back up the new app, and then cross our fingers and hope that everything works.
More often than not, it seems like something goes wrong. Usually we forget to add/populate a new column in the production database that the app now depends on or we mess up and forget to change some property that we need to flip to make the app production ready. Usually an irate e-mail from a user will let me know that something is wrong.
I've been thinking about this lately though, and I think I've finally getting over the deployment hump. Using Maven I've automated all of the property flipping now and have a goal that automatically takes care of pointing the app at the production database. I've also worked in a bunch of Jelly functional tests that go through a bunch of our workflows to assure me that all of our mission critical stuff is working. I'm also working on a tool that will read the schema from both the testing and production databases and create a "database diff" of the two that I can then generate SQL from to bring them back into sync. I'm hoping that this combo of automation and tests will finally end the days of deploying the app and then waiting for the e-mail from one of our users about what's broken this time.

Just saw this on Epesh's site:

One of my original goals for RSSLIbJ was to try to keep the reliance on external jars to a minimum, because it's very annoying to copy a jar file, deploy, run... copy a dependent jar file in, deploy, run... copy ANOTHER dependency in, deploy, run... copy YET ANOTHER dependency in, deploy, run... and oh crap, the dependency requires an older version of this OTHER dependency, which I need to have a newer version of. Even if you don't run into that last snag, it's annoying.

and I agree 100%. We had this problem in spades with Turbine which relies on just about every library under the sun, many of which aren't the released version. Plus it seemed that every developer would have a different version of each library as well, which just added to the fun. We solved the problem by building a dependency mechanism into Maven that downloads specific versions of each jar to use while building a project (one of the driving reasons for building Maven in the first place was to solve this problem), but Java really needs a standard dependency resolution mechanism. I've got the start of something that should solve most of the problems sitting on my hard drive. Perhaps I should finish it up and get _something_ that works out there. (Note: JJAR _doesn't_ work, and I don't like it's monolithic descriptors.) I should be able to hook it in quite easily to Maven now that the massive refactoring is done...

After some more digging, and some talking to James, I've realized that a good portion of my Jelly problems yesterday were due to a bug in Maven. I"m not willing to admit that debugging in Jelly is fun yet, but it's not nearly as bad as I thought it was.

The complete lack of messages as to what's going on behind the scenes when a Jelly script is executing is slowly starting to drive me insane. Some sort of trace mode or debugging functionality should be considered an essential addition before the 1.0 release.

Just to continue the thread about using Blogs and Wikis for projects, Jason is working on a project release plugin for Maven that will automatically create/update an RSS feed when a new version of the project is released (among other things). Maybe I'll finally be able to update my dependencies in a timely manner when I get to see which ones have new releases without digging through all of their websites or subscribing to all of their e-mail lists.

Just a quick note to say that I've finally gotten around to posting the notes from my Apachecon 02 presentation on Apache Turbine here. Feel free to check them out.