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).
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.
- Deployit is (unfortunately) not OpenSource
- 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
- Deployit online documentation
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)