views:

48

answers:

1

We are doing some architecture refactoring. We are a SaaS company so all deploys are to our own self managed servers. Current model packs all of our binaries along with 3rd party libraries we use into ears, wars, tars, etc. These packages include all of the libraries they depend on.

When they are deployed they are manually exploded (untar'd) or picked up by whatever target container they were built for.

Since the libraries don't change much we are wondering if it's a better idea to deploy the libraries before hand, as part of environment setup, and update them as needed. We aren't leaning one way or the other, and I am just looking for some feedback.

+3  A: 

It is generally better to pack libraries with the ears,wars, etc. Some reasons are:

  • It saves time when you configure a new server machine. If you don't package your dependencies with your deployable it can take a long time to get all the correct libraries on a new target server machine.
  • You can deploy different .war files to an application server that depend on different versions of the same library
  • Upgrading a library is straight forward if you package your dependencies with your deployable (simply redeploy). If your libraries are separate you have additional steps to deploy a new library (and another place where things can go wrong).
  • You can be sure that a .war that is deployed on a test environment will behave the same in a prod environment if you include dependencies. Subtle differences in test/prod environments with centralised libraries and versions often cause problems.
  • Your dependency list is really explicit. You can for example do an open source license audit. If you don't package dependencies with your package, you never know...
leonm