At the May meetup of the Melbourne Java and JVM users group, I gave a presentation on how to get a build life cycle up and running using cloud based tools.

This post contains the slides as well as my notes on how to do the demo walkthrough.

First we need something to run

In the demo we need something we can deploy and get working, so lets try and use a Sample ROO application that gives us some basic Spring and Hibernate.

roo.sh script –file $ROO_HOME/samples/clinic.roo

This should give us a simple webapp that we can now quickly and easily launch with Jetty.

mvn jetty:run

Lets take a look at what the application is, notice it has some persistence, but running on hsql.

Before we can get builds and deployments in the cloud, we first need the ……

Source Code in the Cloud

All repositories are remote, so its not a big deal, but as a cornerstone of Cloud development we need our code accessible from anywhere, and so in this case I will use github to create a repo to store this app:

1. Create Github Repo
2. Init local repo
3. Add remote
4. Push repo remote
5. Show commit in github UI.

So now that we have the code in the cloud, lets get to the interesting parts.

Lets work on first getting our code….

Building in the Cloud

Cloudbees are a major sponsor of the Jenkins project, and offer a solution called DEV@Cloud which offers in cloud hosted Jenkins installs.

1. Create new Jenkins job.
2. Configure repo from github
1. Use http method
2. Remove stevemac@

So now we have the code there and it builds, but this is probably not much than we are already used to.

Now it’s time to setup our …

Hosting in the Cloud

This is probably what we all came to see, and I’m sorry to say that it’s been made really easy.

Let’s start with the fully manual process.

mvn package

1. Log onto cloudbees control panel
2. Create a new application
3. Browse to upload WAR file
4. Demo the site running.

At this point we have completed the brief, we have code and builds and deployment in the cloud, but its still a little bit disjointed.

Lets take the next step and connect some dots.

Scripted deployments to the Cloud

Again the guys at CloudBees have done lots of the heavy lifting, they have a maven plugin that helps automate the deployment process.

<build>
	<finalName>myapp</finalName>
	<plugins>
		<plugin>
			<groupId>com.cloudbees</groupId>
			<artifactId>bees-maven-plugin</artifactId>
			<version>1.2.2</version>
		</plugin>
	</plugins>
</build>

<pluginRepositories>
	<pluginRepository>
		<id>bees-plugins-releases</id>
		<url>http://repository-cloudbees.forge.cloudbees.com/public-release/</url>
		<releases>
			<enabled>true</enabled>
		</releases>
		<snapshots>
			<enabled>false</enabled>
		</snapshots>
	</pluginRepository>
</pluginRepositories>

Now that we have this installed, we can use the ‘bees’ goals to control our application. Its quick and easy to deploy changes.

Lets make a change to the app so we know its deployed.

1. Open project in eclipse
2. Edit index page add some text.

mvn bees:deploy -Dbees.apikey=<apikey> -Dbees.secret=<secret> -Dbees.appid=stevemac/XXX

These values shown here are the api-key and secret supplied by cloudbees, and the appid we previously setup.

We now should see on our new application with changes.
We now have all the moving pieces, and a repeatable deployment, but what would be great is…

Continuous Deployment in the Cloud

Lets take this application the next step.

We now have local changes that are deployed to our test server, but there is no guarentee that the build and application are repeatable, we really should be deploying from our source repository, not developer machines.

So lets make that happen.

The custom Jenkins install offered by CloudBees contains a really nice option to enable deploying to cloudbees on successful builds.

1. Enable the option
2. Make another change to application
3. Add and Commit to git
4. Push changes
5. Watch build occur

Now we have full roundtrip development, from developer desktop, through source control, build and test server and deployed out to hosting.

So now that we know we have a full build pipeline, but notice, the application is still pretty useless, it still runs the embedded HSQL and so on each re-deployment we lose our information.

Let’s upgrade the product to use an external database, but where will it be but….

MySQL hosted in the Cloud

Please don’t take this as an advertisement for CloudBees, but they were the first provider I found that offered the full stack for FREE that I could test out.

First we need a database to store our information on

1. Login to cloudbees control console
2. Create cloudbees mysqldb
3. Open MySQL browser and login

Now we need to upgrade the application with the settings

1. Update the persistence.xml
2. Update the applicationContext
3. Update web.xml
4. Create cloudbees.xml file

Persistence.xml

<property name="hibernate.dialect" value="org.hibernate.dialect.MySQLDialect"/>

ApplicationContext.xml

<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
	<property name="jndiName">
		<value>java:comp/env/jdbc/melbjvm</value>
	</property>
</bean>

Web.xml

<resource-ref>
	<res-ref-name>jdbc/melbjvm</res-ref-name>
	<res-type>javax.sql.DataSource</res-type>
	<res-auth>Container</res-auth>
</resource-ref>

Cloudbees.xml

<cloudbees-web-app>
	<appid>stevemac/melbjvm</appid>
	<resource name="jdbc/melbjvm" auth="Container" type="javax.sql.DataSource">
		<param name="username" value="melbjvm" />
		<param name="password" value="melbjvm" />
		<param name="url" value="jdbc:cloudbees://melbjvm" />
	</resource>
</cloudbees-web-app>

Now you don’t want to have to push to production to test it, it would be great to be able to run this locally and make sure we have it all right first wouldn’t it.

So lets do that, the CloudBees plugin allows you to run a Tomcat container using these configurations locally.

mvn bees:run

Add now we can see in the MySQL browser the database has been created.

So let’s check in all these changes and let the application be deployed.

1. Git add,
2. commit,
3. and push
4. Watch build

But our tests fail

I know they do, so (being naughty) I’m just going to skip them, kick off the build again and watch it deploy.

Thats pretty much the demo

If we have time, show off Jelastic, at least the application control panel.

How to Setup Jelastic

Build plugin

<plugin>
<groupId>com.jelastic</groupId>
<artifactId>jelastic-maven-plugin</artifactId>
<version>1.7-SNAPSHOT</version>
<configuration>
<email>${jelastic.username}</email>
<password>${jelastic.password}</password>
<context>ROOT</context>
<environment>melbjvm</environment>
<comment>${buildNumber}</comment>
<api_hoster>app.jelastic.servint.net</api_hoster>
</configuration>
</plugin>

<pluginRepository>
<id>sonatype-oss-public</id>
<url>https://oss.sonatype.org/content/groups/public</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</pluginRepository>

• JasperForge: JasperReports Project Forums
  Open Source Business Intelligence Platform for deploying open source reporting, analysis, and data integration tools utilizing J2EE, Java open standards.
  (tags: jasperreports images)
• CREATING JASPER REPORTS WITH DYNAMIC IMAGES « Gilbert Adjin’s Tech Blog
  (tags: jasperreports images)