Cloudbees

I’ve been using CloudBees a lot recently for deploying to ‘the cloud’.
There are a couple of things that attract me to CloudBees…

Jenkins builds via DEV@cloud

The first is the what CloudBees call DEV@cloud and what I simply think of as an online Jenkins instance. I am a big Jenkins fan (at home and work) and having a cloud based Jenkins instance is invaluable. The GitHub integration means I can check in code and have all tests run and a war file build automatically. I tend to use maven as the build tool for my projects, so with DEV@cloud’s ‘Poll SCM’ turned on, all I have to do is check in a change, and it builds. Nice.

Automatic deployment to the cloud via RUN@cloud

The second cool thing about CloudBees (and the deal winner for me) is the automatic deployment option. When I check in a new piece of code, not only will CloudBees do a maven build for me, it will also deploy it to the cloud. And all it takes is clicking a single checkbox. Literally. They couldn’t possibly have made it any easier. By default, it will be given a URL such as yourappid.youruserid.cloudbees.net, but this is configurable. The cloud deployment is what CloudBees call RUN@Cloud

And beyond…

At a certain point of course, you need to start being more specific about how to deploy an app than just saying ‘deploy it’. That is when the Cloudbees SDK comes into play. Download it and you can then start specifying details of the deployment such as a specific JVM/Java/JRE version, memory options, security, scalability etc.

So far, I’ve been using CloudBees for prototypes such as this Handsontable / SpringMVC example, a SpringMVC file download example, a SpringMVC HelloWorld template I use for bootstrapping projects, and a simple app for managing money called MyMoney. But everything I’ve seen suggests CloudBees as a viable solution for live, production cloud-based apps.

For the record, I have no relationship with CloudBees other than a happy user.

Tags: cloud, cloudbees, continuousdeployment, continuousintegration, jenkins, Maven