5

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.

Improve this question
3
  • There are ways to deal with PermGen issues: stackoverflow.com/questions/88235/…
    – Bernard
    Dec 11, 2011 at 15:37
  • Believe me I've tried to get rid of the issue but none of the solutions have worked. It would be much safer to just restart Tomcat than to try to redeploy.
    – palto
    Dec 11, 2011 at 15:54
  • Have your script restart Tomcat on a regular basis.
    – user1249
    Dec 14, 2011 at 9:46

4 Answers 4

Reset to default
4

Disclaimer: I'm an unpaid advisor for their product advisory board.

Zero Turnaround have very low cost products called JRebel and LiveRebel which solve a vast majority of the issues dealing with hot deploying WAR files to a web server such as Tomcat.

As smp7d correctly mentions, JRebel is the development tool version of the two.

They tend to work at the byte code level, avoiding the often broken class loading system in this space.

Improve this answer
4
  • +1 There seems to be an UI for deploying a specific version to production without manual steps. Great.
    – palto
    Dec 13, 2011 at 12:44
  • Note: JRebel is only meant to be a development tool.
    – smp7d
    Dec 13, 2011 at 13:54
  • @smp7d - Good point, edited my answer.
    – Martijn Verburg
    Dec 14, 2011 at 9:41
  • This is for development!! It is not meant for production. And this is not continuous delivery, but hot deployment
    – Tejas
    Dec 28, 2015 at 9:37
2

You could restart Tomcat and be done with it. Also, Tomcat 7 has supposedly solved PermGen issues... although I haven't tried.

Improve this answer
6
  • Except how do I automatically restart Tomcat?
    – palto
    Dec 13, 2011 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.
    – alex
    Dec 13, 2011 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.
    – palto
    Dec 13, 2011 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
    – alex
    Dec 13, 2011 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.
    – user1249
    Dec 14, 2011 at 9:47
1

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

Improve this answer
4
  • This totally depends on the server, the environment, the app, etc.
    – Dave Newton
    Dec 13, 2011 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?
    – palto
    Dec 13, 2011 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.
    – BillThor
    Dec 13, 2011 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.
    – palto
    Dec 13, 2011 at 19:17
0

I think you could increase the PermGen szie(-XX:PermSize=64M -XX:MaxPermSize=128m),this default value is 64M. If you do not want to increase it ,you may be could use ANT to deploy your web app.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.