I've been reading about Continuous Delivery and it sounds awesome to automate the deployment process. I've been reading about possibilities how to do this with Java Webapps, but usually it ends up with CI server or maven plugin deploying to Tomcat WITHOUT restarting the Tomcat using Tomcats management API. But that leads to OutOfPermGenSpace issues and so I wouldn't use those solutions for production. In addition it is a hassle to kill an out of control Tomcat.

Is there any technology that would make it easy to deploy Java web apps to production? I use maven to build my artifacts and deploy to nexus repository.

EDIT:

I'm not trying to find ways to prevent Permgen space issues. I'm trying to automatically deploy to production. There should be no manual steps beyond choosing a version and clicking a button(or giving a version number to a commandline script). I want to find out if I have to create this kind of setup manually, or if there is a ready made solution for this. Thus far LiveRebel seems to be the only solution so far that doesn't require me to implement everything myself.

Except how do I automatically restart Tomcat?
–
paltoDec 13 '11 at 12:46

Tomcat, as downloaded from Apache, can be restarted using $TOMCAT_HOME/bin/startup.(sh|bat) and shutdown IIRC. If you are using a Linux distro's Tomcat or similar, you might need to do something else (invoke a /etc/init.d script, perhaps). You should be able to plug that into whatever deployment system you use.
–
alexDec 13 '11 at 18:03

I already know how to start and stop Tomcat :) So the answer here would be to write a script for the CI that would: 1. Stop tomcat service and clean work directory 2. Copy war to tomcat webapps dir 3. Start tomcat service. I was hoping to find a solution that could do this without me writing such scripts, though it looks like I just might have to.
–
paltoDec 13 '11 at 19:22

Well, you might want to post what are you using for CI- I'm not familiar with them, but someone might be and offer you some help
–
alexDec 13 '11 at 21:04

@palto, as a developer you should know that the world is never perfect and you need to add a bit of code here and there.
–
user1249Dec 14 '11 at 9:47

You should only be doing Continuous Delivery to a development server. Look at deploying changes to an exploded application on this server. If this isn't suitable increase the PermGen size. Schedule daily restarts of the server to clear the memory.

Tag and build a deployment package for the Integration Server and only deploy when requested. This should be co-ordinated with the Integration testing team. I find that more than once a day is usually excessive for this environment.

Deployment of the tested deployment package from the Integration Server to Production should only be done on approval. This usually needs to be scheduled for off-hours.

EDIT: Everywhere I've worked where we had automated deployment it has been hand crafted. There tend to be issues around privileges, approvals, schedules, etc. that might make a generic product not fit well in a particular environment. In environments with multiple load balanced servers, there can be additional issues.

EDIT2: I have always advocated automated deployment. Continuous deployment as I have experience it is build and deploy on check-in. You don't want production to be the deploy target. It is a good way to ensure things build in the target environment and not just on the developers desktop.

Picking off builds as deploy candidates for further testing and possible production deployment is not what I would consider continuous deployment. I do consider it a best practice if the selection and migration is automated

This totally depends on the server, the environment, the app, etc.
–
Dave NewtonDec 13 '11 at 3:54

But it should be possible to deploy to production automatically, no matter how many teams you have to co-ordinate with. And isn't deploying rapidly to production the whole point of Continuous Delivery?
–
paltoDec 13 '11 at 12:45

It takes an extremely experienced and disciplined team to safely deploy directly to production. I've lived through a week where production was down because we couldn't get a stable build into production. I didn't get the impression that was the case here.
–
BillThorDec 13 '11 at 17:53

What does deploying DIRECTLY to production mean? When you have a binary that you are satisfied with you deploy it. I don't mean by Continuous Delivery that you skip testing. Also I've lived through a day where we had a borked release. For the whole day we were figuring out a bug that was caused by mistake in the manual deployment. If we would have automated our deployment and TESTED it on production like environment we could have prevented that. We tested the manual deployment but still made a human error when deploying to production.
–
paltoDec 13 '11 at 19:17