Deployit, deployment automation made easy

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…​

Nicolas Fränkel

Nicolas Fränkel

Developer Advocate with 15+ years experience consulting for many different customers, in a wide range of contexts (such as telecoms, banking, insurances, large retail and public sector). Usually working on Java/Java EE and Spring technologies, but with focused interests like Rich Internet Applications, Testing, CI/CD and DevOps. Also double as a trainer and triples as a book author.

Read More
Deployit, deployment automation made easy
Share this