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.
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:
- Create Github Repo
- Init local repo
- Add remote
- Push repo remote
- 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.
- Create new Jenkins job.
- Configure repo from github
- Use http method
- 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.
- Log onto cloudbees control panel
- Create a new application
- Browse to upload WAR file
- 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.
- Open project in eclipse
- 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.
- Enable the option
- Make another change to application
- Add and Commit to git
- Push changes
- 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
- Login to cloudbees control console
- Create cloudbees mysqldb
- Open MySQL browser and login
Now we need to upgrade the application with the settings
- Update the persistence.xml
- Update the applicationContext
- Update web.xml
- Create cloudbees.xml file
<property name="hibernate.dialect" value="org.hibernate.dialect.MySQLDialect"/>
<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean"> <property name="jndiName"> <value>java:comp/env/jdbc/melbjvm</value> </property> </bean>
<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-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.
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.
- Git add,
- and push
- 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