Starting Dropwizard in deployment environment

[Adam Parrish]

Guys:

I am just looking to see how you envision dropwizard running in a deployment scenario. I'd imagine if I am checking code into SVN or Git I would just sync up with a tag and run a script to recompile my Jar or just deploy a precompiled Jar to a deployment machine. 

Then ssh into the machine and fire it up with nohup. Is there any other way to do it that you guys are using in a semi-production-esque way?

-Adam

[Tatu Saloranta]

Companies I've worked for have always had separate deployment systems,
never using build system directly, or allowing (much less requiring)
copying of artifacts manually.
But unfortately they all tended to be proprietary ones.
With one exception: Ning's Galaxy:

https://github.com/ning/galaxy

which is open sourced. Whether it'd be useful for you I can't say; but
for what it is worth it is used by multiple companies (as-is or
modified) outside of Ning. And it is not too different from systems
used by other companies that I am familiar with.

Poor man's method might indeed be doing "mvn package", scp over jar,
and then issuing ssh commands to stop old instance, restart new. But
it's nicer to have bit more advanced system; galaxy sort of automates
this concept. It just requires a repository of deployment artifacts
(which includes jar, plus couple of scripts), which are packaged
usually using Maven, scp:ed to repository (can be simple http server).
And then scp:ed from there. Supports basic versioning, gives you a
view of all deployments, states.

-+ Tatu +-

[Richard Crowley]

On Mon, May 21, 2012 at 10:58 AM, Adam Parrish <wapa...@gmail.com> wrote:

Jenkins runs `mvn package` and wraps the resulting jar in a Debian
package using FPM [1]. Puppet updates that package from our Debian
archive [2] and restarts the Upstart service that runs the jar.

Upstart is rough around a lot of edges but really gets
run-this-program-and-restart-it-when-it-dies-or-I-say-so right.

[1] https://github.com/jordansissel/fpm
[2] https://github.com/rcrowley/freight

Richard

[Coda Hale]

Our deploy pipeline looks like this:

1. An engineer makes a change to the code base and pushes it to the git repo.
2. Jenkins notices the change and runs ``mvn deploy`` on the new machine.
3. Maven uses maven-shade-plugin to build a single JAR file with a
MainClass which includes all the projects' dependencies.
4. Maven deploys this JAR as an artifact to our repository in Nexus.

The deploy story then looks like this:
1. Log into all the hosts via SSH.
2. Use curl or wget to download the JAR file for the version you're deploying.
3. Place it in the expected directory.
4. Signal to Upstart to restart the service.

(This is, of course, highly automated.)

But this is specific to how we work at Yammer.

The important, generalizable parts are:

* Deploy a single artifact to all environments. Re-compiling
everywhere introduces confounding factors for QA.
* Bundle your dependencies with your own code. If you need to bump a
library version, re-deploy the application. (If the application is
hard to deploy, fix that first.)
* Use continuous integration.
* Use an artifact repository.

I hope this helps.

On Mon, May 21, 2012 at 10:58 AM, Adam Parrish <wapa...@gmail.com> wrote:

--
Coda Hale
http://codahale.com