Tag: continuous deployment

Posted on

JRebel 5.0 – 5.1

I was on the verge of doing a new write up but due to work I couldn’t get very far. I had compiled some text into a file and here it is:

In JRebel 5.0 I noticed some stuff.

It seems that JPA NamedQueries are not changed on reload. It is not certain that this is supported, about that unsure I am.
Spring 3.1 MVC Controllers are not reloaded (Luckily there is always the nightly build of JRebel and it fixed that when I was using 5.0!)
Another thing I noticed is that Spring Reloadable Message bundle new properties are not reloaded
And then the good stuff! better IDE integration, easier single click activation of JRebel for multiple projects thanks to the JRebel Config Center making a developers life much much more comfortable. Almost all latest Java Frameworks are supported!

JRebel 5.1

At work I’m making an app called ECW it’s not that big, only 11k lines of code. But I got some stats, and remarks by that statistics.

Tomcat Startup times:
ECW no JRebel = INFO: Server startup in 6255 ms
ECW with JRebel = INFO: Server startup in 13420 ms

Of course the doubled startup time is is neglectable! Why? You almost don’t have to restart tomcat the whole day!

an issue I had an fixed was:
Java 7 and Java 6 mixed … Not working. By default JRebel seems to be using Java Version of eclipse, instead of the version used for project/compilation/running tomcat, setting JAVA_HOME to java6 and still using -vm jdk7 to run eclipse , fixed the issue. This is probably documented in the documentation but I didn’t see it come up in the google search 🙂

And then some more stats:

JRebel 5.1.0 (201210161346)
[2012-11-27 21:57:38] (c) Copyright ZeroTurnaround OU, Estonia, Tartu.
[2012-11-27 21:57:38]
[2012-11-27 21:57:38] Over the last 30 days JRebel prevented
[2012-11-27 21:57:38] at least 193 redeploys/restarts saving you about 2.4 hours.
[2012-11-27 21:57:38]
[2012-11-27 21:57:38] Over the last 84 days JRebel prevented
[2012-11-27 21:57:38] at least 577 redeploys/restarts saving you about 7.1 hours.

Stats are always fun! What can ZeroTurnaround do to make them more fun?
Add a total time a server was running with JRebel. And perhaps the total deploys that happened during that time. Instead of just notifying the time saved. In the case of the above stats 2.4 hours seems very little, and 7.1 hours over 84 days, maybe even less. IMHO the stats would say much more if the total manual deploys are visible too.
Something like:
[2012-11-27 21:57:38] Over the last 84 days JRebel prevented
[2012-11-27 21:57:38] at least 577 redeploys/restarts saving you about 7.1 hours.
You had 168 (taking about 3.7 hours) manual deployments over a total running time of 240h.

You can do the math yourself from the above stats. Suppose that I had to manually deploy those 577 everytime. I would have lost 1 day in 240h ( 30days).

Points where JRebel could improve. If technically possible.

Deploy new classes, and a whole class tree (e.g. when a superclass changed), add new properties that are added in properties files. (Disclaimer: perhaps JRebel can do all that and is illconfigured at my side)

What did I conclude from using JRebel the last 3 months?

  • the bigger the app the more useful it gets!
  • if I disable it for a day I have to go to a rehab center
  • stats can be more irie
  • I love zeroturnaround, but it’s to far from home to even consider sending them my resumé

Note: Now that they made LiveRebel free for 2 servers it is time to try it! (and buy it for all your servers)

 

Disclaimer: I do not work for ZeroTurnaround, neither am I affiliated to them in any way!

Posted on

JRebel time-savings

I’ve been using JRebel for little more then a month now on the yellow pages project. It think it’s safe to say it saves me about a day of waiting for deployments in a 30 day time frame.
UPDATE: I forgot to mention, on those 30 days I worked only 12 days. I think JRebel stats don’t take that into account so it’s more like 2 days in 30.

In the previous post I wrote that the actual time savings is probably a bit less because you can do other stuff. But during Devoxx Joachim claimed ‘you safe more then JRebel shows you’. And you know what, he’s right.

What happens without JRebel?

You deploy, restart server. During waiting time you check email or twitter or stare outside thinking … (fill in what you do). This means you get distracted from your ‘coding flow’. You get distracted more often then every 25 minutes.

What happens when JRebel is active?

You don’t deploy, JRebel does that for you when hitting a page that has changed Java code behind it. This means you don’t start reading email or twitter or … Hence you don’t get distracted and can stay in your ‘coding flow’. You don’t have to refresh your memory every time you turn back towards your IDE to pick up where you left before deploying and reading email or …. Consequence: you can keep writing code and don’t get distracted, most likely resulting in better code.