Building your own Continuous Integration with Mule Cloud Connect and iON

motif

As you probably already heard we launched Mule iON this week. If you ask one of our marketing guys what iON is, he will tell you that is the first cloud-based integration platform. iON will enable you to integrate popular SaaS applications, cloud services, social media, and a lot more without requiring any infrastructure.

Of course, I’m not a marketing guy, I’m a software developer. So my description is: “iON is awesome. It’s Mule on the cloud, and you are totally going to dig it”. Also, since I’m a software developer, I will put my money were my mouth is and I will show you how to build something incredible in a couple of minutes. Thats right! A few minutes and thats taking into account your learning curve of Mule iON.

Continuous Integration

If you are a software developer you probably heard about continuous integration. Continuous integration is the process of continuously verifying the quality of a software product. That means that instead of waiting until you are done to actually test a product you actually continuously test the quality as you develop it.

That is exactly what we are going to be building today. A Mule iON application that will do continuous integration of Maven-based projects. The application will connect to a database hosted at MongoHQ which will contain the list of applications to continuously integrate, then it will connect to their GitHub repositories, perform a clone of them locally and then invoke to actually build them.

So, the integration will be between GitHub, Mongo and Maven. In order to simplify this, we are going to be using the following components:

* MongoDB Connector
* Git Connector
* Maven Connector

Except for the MongoDB (which uses the original connector model) everything else was developed using our Mule Cloud Connect dev kit, and you will see how incredible easy it makes for you (the integration developer) to use different cloud services.

Retrieving the list of repositories

The first thing our flow needs to do is retrieve a list of GitHub repositories to continously integrate. To do that, we will configure a database on MongoHQ which will have a single collection called repositories. That collection will contain JSON documents like the one in the following example:

Let’s declare the database connector:

Querying the collection is as easy as doing the following:

Notice we only needed to specify the collection name, this transport will poll that collection at the interval specified in the connector configuration under pollingFrequency.

Cloning a Git repository

So, now that we know how to retrieve information from Mongo, we need to take each Git URI on each document and clone it locally so we can build it and test it. In order to do that we are going to use the Git Connector. You can use the Git connector in your flow just by declaring it as follows:

The directory property just specifies the default location for the local copies of the repositories. You can override it on each Git operation. Cloning is as easy as configuring the connector:

This will clone the URI that will be taken from URI json field in the message payload to the directory specified in the directory message header. Simple, uh?

Verifying the quality

Now that you know how to get a local copy of a Git-managed software project, it is time to actually test its quality. To do that we will use the Maven connector and use the test goal. Again, declaring the connector is as easy as:

And executing a goal, equally simple:

Wiring everything in a Mule Flow

Its time to cross the finish line. You already know how to do the individual pieces involved in doing continuos integration, its time to put a flow together and will wire everything up. Let look at a diagram of the flow, and then we will dive into the XML:

The following is the XML version of the flow:

I made one optimization in this flow, which is that if the repository is already cloned we just updated instead of cloning the whole thing again saving time and bandwidth.

Derivative Work and Demo

We are using a derivative of this internally to build javadoc for several of our projects hosted in GitHub. If you are curious you can find the source for our project here. Here is a link directly to our app flow. It is based on this very same idea, except that it is a little more complex but it shows how much you can do with just a few lines of XML.

Our fully working project which is running in iON can be accessed here: javadoc.muleion.com


We'd love to hear your opinion on this post


One Response to “Building your own Continuous Integration with Mule Cloud Connect and iON”

  1. […] this blog post, Emiliano Lesende shows us how to build a Mule iON application that does continuous integration of Maven-based projects. The application connect to a database hosted at MongoHQ thatl contains the list of applications to […]