Over a million developers have joined DZone.

Deployit, Deployment Automation Made Easy

DZone's Guide to

Deployit, Deployment Automation Made Easy

· DevOps Zone
Free Resource

The Nexus Suite is uniquely architected for a DevOps native world and creates value early in the development pipeline, provides precise contextual controls at every phase, and accelerates DevOps innovation with automation you can trust. Read how in this ebook.

Two weeks ago, I attended the first Swiss JDuchess workshop in Geneva. It was about Deployit, a software to enable continuous deployment. I had already been introduced to it at Devoxx France 2012, and it had been a surprise… a very good one.

Unfortunately, the workshop was a failure, at least for me: I couldn’t import the provided Virtual Machine. Given the very positive feedback of the other attendees, I decided to run it some time later at home. This time, it worked like a charm.

By the way, congrats to Benoit Moussaud, Technical Director at Xebialabs France, because everything in the workshop works flawlessly. I’ve attended paid trainings with material of much worse quality.

Deployit is based on the following core concepts:

  • Deliverables are versioned artifacts to be deployed, e.g. a WAR, a EAR, a ZIP archive of web resources, a SQL script, …
  • Environments are containers artifacts run in, e.g. a servlet container, an application server, a web server, a database, …
  • Bindings between a pair of the former
  • Dictionaries to resolve placeholders, so that the same deliverable can be deployed in different environments

There’s no magic in how Deployit works, it uses existing parts of modern development environments, most notably CI servers. The only requirement is to have a dedicated Maven project that creates so-called DAR archives, which are nothing more than ZIP files wrapping all resources mandatory for a deployment. A dedicated Jenkins plugin takes care of providing produced artifact to Deployit console.

At that point, only one action is necessary: bind between each resource and a container (or multiple containers). For example, I would map the WAR to Tomcat and the SQL scripts to MySQL. Even better, if matching tags are set on both deliverable and environment, this step becomes optional. Also, providing the right dictionary for this deployment plan may also be needed (see above).

Deployit admin console

Now, the Jenkins plugin is able to see the plan, so we can launch it as part of the build process! In effect, this means we achieved a whole automated build pipeline, from compiling to deployment and including all needed tests.

Of course, there are some more features provided by Deployit (for example, how to launch a plan with the CLI, but those are only nice-to-have, not core. If you want to see more, I suggest heading toward the product page.


  1. Deployit is (unfortunately) not OpenSource
  2. I don’t know about any Deployit competitor. Hints welcome as I think competition is a sure way to up the ante…

To go further

The DevOps Zone is brought to you in partnership with Sonatype Nexus.  See how the Nexus platform infuses precise open source component intelligence into the DevOps pipeline early, everywhere, and at scale. Read how in this ebook


Published at DZone with permission of Nicolas Frankel, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}