deploying a .war or an .rpm?

[Tomer]

Hi

I watched one of the interesting continuous deployment lectures at
youtube and I had this question.

How to release a .war?

Basically i'm trying to decide if i am releasing a .war or an .rpm
that contains that .war

there are many options:

* Deploy the .war itself?
* Or maybe package the war in .rpm that will both throw the war and
then do some self-test - an rpm that will perform the uninstall
unconfigure and later on the install configure?
* throw the .war and have a separate script that will perfrom the
uninstall unconfigure etc...
* More?

I tend to like the .war inside .rpm style I just think it might be too
much, after all the concept of deploying a war is copying it into a
directory and now i involve an .rpm and the os might store the history
of rpm upgrades that where made...

which do you recommend?

thanks
Tomer

[Eishay Smith]

IMO rpm is the way to go. It configures the runtime env of your web application, e.g. env vars and checks/retrieves files. yum is a good system to manage application installation, versioning, local caching and rollbacks. If you use plain war you'll need to reinvent the wheel. 

[Pavel Suchman]

Hi,

I am doing deployments for a company that has about 20 wars in the product.

There are tens of machines and some machines have 7-8 wars.

In that scenario packing (the same) scritps with each war in an RPM wouldn't be an elegant solution, so we keep the scripts and the wars separated.

However if you have only 1 or 2 wars and don't plan to increase their number in the near future, packing everything in an RPM might be a good idea.

Best,

Pavel

[Ran Tavory]

I agree with what Eishay says, packaging a war in an RPM is beneficial in terms of OS support for upgrade/downgrade, caching etc. At outbrain this is what we do.

In the case of outbrain we also enjoy atomicity of installment, so for example you may install an RPM (using yum) from the command line if you need to, without depending on other deployment tools, and it would still do the right thing, and we heavily use RPM's pre and post install scripts to start/stop tomcat, repackage the war, cleanup etc, so this is something that's easily baked into RPM that you would have to reinvent if you only copy a war file. For example, we only package 'thin' wars, which contain ourbrain's specific jars, and all the rest of the 3rd party jars are cached locally on the host such that the RPM post install script repackages them into the war before handing the war over to tomcat. (so we conserve bandwidth and time)

I should note, though, that the process is not without pain sometimes, so for example we need to maintain a yum repo for each DC with failover between them (and if you use a war only you would have to do something similar just for the wars), and we have to take care of occasional yum failures on the hosts, which naturally can happen. Of course this is true even if you deploy your wars without RPM (shit happens no matter what you do or how you do it), but if there are less moving parts it's easier to understand the shit. I would still recommend packaging in RPMs, just wanted to note that first you add another moving part to the system which may fail and second you have to understand RPM and yum which are not rocket science, but there are things to learn before they can work for you. And you have to teach other folks in your company so they would understand them as well...

--

/Ran

http://tavory.com

[Tomer]

thanks got it.

> On Tue, Mar 6, 2012 at 10:29 AM, Pavel Suchman <pavel.such...@gmail.com>wrote:
>
>
>
>
>
>
>
>
>
> > Hi,
>
> > I am doing deployments for a company that has about 20 wars in the product.
>
> > There are tens of machines and some machines have 7-8 wars.
>
> > In that scenario packing (the same) scritps with each war in an RPM
> > wouldn't be an elegant solution, so we keep the scripts and the wars
> > separated.
>
> > However if you have only 1 or 2 wars and don't plan to increase their
> > number in the near future, packing everything in an RPM might be a good
> > idea.
>
> > Best,
>
> > Pavel
>
> > On Tue, Mar 6, 2012 at 10:05, Eishay Smith <eis...@gmail.com> wrote:
>
> >> IMO rpm is the way to go. It configures the runtime env of your web
> >> application, e.g. env vars and checks/retrieves files. yum is a good system
> >> to manage application installation, versioning, local caching and
> >> rollbacks. If you use plain war you'll need to reinvent the wheel.
>