Continuous Delivery with DEV@cloud and Cloud Foundry

This morning, we announced support for deployment from DEV@cloud Jenkins build jobs to Cloud Foundry's PaaS: I've done a short video that shows how easy it is to set this up (we've done ClickStarts with a couple of well-known Spring/Grails projects) and I've also written a guest blog on the Cloud Foundry site that goes through how it all works. I'm really happy to see this integration - our vision for DEV@cloud is all about a complete, fully cloud-based continuous delivery platform, regardless of where you choose to run the applications that you build.

Rather than cover the same ground as the Cloud Foundry blog, I wanted to drill down a little into what's going on and how you can use this in your own projects: I've included a couple of examples, based on the ClickStarts, on our partnerdemo account that you can use as a reference.

First, let's take a look at how we secure access from your CloudBees DEV@cloud account to the Cloud Foundry deployment services. CloudBees and Cloud Foundry both support the industry-standard OAuth 2.0 protocol, allowing you to establish a trust relationship between your accounts without the need for either party to store account details like passwords from the other service. To do this, just go to https://cloudfoundry.cloudbees.com , which will redirect you to the standard Cloud Foundry log in page. Log in with your Cloud Foundry credentials and authorize your CloudBees account to deploy to your Cloud Foundry account:

You'll be asked to confirm that authorization on the CloudBees side as well and you'll get an email confirmation: if you happen to have multiple accounts associated with your CloudBees login email address (I'm guessing most people don't, but just in case you do), then you can choose which accounts you want to link to your Cloud Foundry account. The other thing to bear in mind is that it's quite normal for an OAuth token to expire - in fact it's a good thing and you should expect to be asked to re-authorize your account periodically. I believe that Cloud Foundry's current policy is to ask you to renew authorization every 30 days, but of course that might change. Anyway, CloudBees will send you an email to let you know if any of your builds are unable to deploy to Cloud Foundry because the auth token has expired, so you'll be able to take action. Just go to cloudfoundry.cloudbees.com and re-authorize for that account.

For deployment to Cloud Foundry, choose "Deploy applications" from the Post-build Actions drop-down menu in the usual way, and when you go to select a Host Service you'll see "Cloud Foundry" as an option with "CloudBees RUN@cloud service". In fact, if you've already enabled deployment to Google App Engine, you'll see that as an option as well. The whole mechanism for adding deployment targets is completely generic: if you're curious, take a look at the installed Jenkins plugins for your account and you'll see how it works. There's a Cloud Foundry Deploy Engine Plugin that manages the actual deployment, plus OAuth Credentials and Token Provider plugins. There's also a Cloud Foundry ClickStarts plugin, which provides a convenient launcher for the Spring and Grails ClickStarts - you'll see that in your top-level Jenkins menu.

Modulo the OAuth mechanisms, which we clearly don't need for our own services, the way we deploy to RUN@cloud works in exactly the same way: there's a CloudBees Deployer Plugin that implements those same interfaces to make RUN@cloud a Host Service, just as we do for Cloud Foundry and Google App Engine. That might seem surprising, but we're very serious about making the cloud an open space for continuous delivery, however you decide to deploy your apps.

The details of how to configure the Cloud Foundry deployment are shown below. This is taken from the Grails PetClinic application, which is one of the two ClickStarts that we provide to get you started:

There a couple of points to notice here. We follow the Cloud Foundry convention and omit the scheme when specifying the Deployment URL; however, don't forget that this needs to be unique. There are plenty of ways to do that, but for the ClickStarts I decided to add -${account} to the application name, so that the actual deployment URL would be e.g. http://petclinic-grails-partnerdemo.cloudfoundry.com.

Note also that this application uses a MySQL service on Cloud Foundry and we can simply specify this as part of the deployment. When I took the screenshot, the job had already run, so that's why you see the message that the service exists and will be bound to the application as-is: if you create a job from scratch, you'll see an equivalent message that the service doesn't exist and will be created for you. You don't need a globally-unique name for services, by the way, so no need for the -${account} trick. The Spring example uses postgres and redis services in exactly the same way. There is full documentation on how to use the plugin to deploy from DEV@cloud to Cloud Foundry on the Cloud Foundry GitHub site.

That's pretty much it. We've pre-configured things on DEV@cloud to use a pre-installed 2.2.0 version of Grails, to make the build go faster. If you're setting up your own Grails jobs, don't forget that you need to configure the Grails installation(s) as part of the Jenkins global settings (Manage Jenkins -> Configure System -> Grails). If you're interested in how we built the ClickStarts, you can find them on GitHub.

• Try CloudBees DEV@cloud on Cloud Foundry - it's all free: https://cloudfoundry.cloudbees.com

Mark Prichard, Senior Director of Product Management

CloudBees

cloudbees.com

Mark Prichard is Java PaaS Evangelist for CloudBees. He came to CloudBees after 13 years at BEA Systems and Oracle, where he was Product Manager for the WebLogic Platform. A graduate of St John's College, Cambridge and the Cambridge University Computer Laboratory, Mark works for CloudBees in Los Altos, CA. Follow Mark on Twitter and via his blog Clouds, Bees and Blogs.