How we made our Community Plug-ins Easy as Pizza

| September 24, 2014 | 0 Comments

Because we support different stacks of middleware, we wanted to make open source plug-ins available to everyone. In this way, our customers have the ability to copy the source code and build new plugins from source.

In the past we created a single repository on GitHub for our community and open source plugins. But, there was a serious limitation to this repository, since it was difficult to search. Each directory contains multiple plugins, and the nested subfolders make it difficult to find what you’re looking for. Not good! Because of this nesting structure you had to click your way down the tree multiple times to find your plugin. (btw – the repository still exists if you want to have the source code: https://github.com/xebialabs/community-plugins). The problem got worse because many users have expressed that they don’t want or need to see the source code. Users told us that they really just want access to the compiled version of the plugin. So we took it upon ourselves to make life simpler. We created a new place on GitHub called XebiaLabs Community (https://github.com/xebialabs-community), where each community plugin will have its own repository. This way we already got rid of the complicated nesting structure.

Screenshot from 2014-09-24 13:03:44

xebialabs community organization

With this new format you can easily search the plugin you’re looking for. In the “Find a repository” field you can fill in the plugin you’re looking for and GitHub will show you the matching community plugins. Today we have many plugins, including ServiceNow, Jenkins, SharePoint, CloudFoundry and many others. We’ll continue to migrate the plugins that are in the old structure, one by one, into the new more user friendly structure. And we also solved the second problem, making compiled version available ready for download. For example, if you browse to https://github.com/xebialabs-community and click on the Jenkins plugin, you’ll note you can still see the source code. But unlike before, now you can download a release and start using it. Simply go to the release tab and dowload the jar file. No need to compile it. Simply download the JAR file, place in your <SERVER>/plugins directory and restart.

Jenkins XLD plugin

Jenkins XLD plugin

Continuous Integration
We also added continuous integration to those plugins. When we build them in this automated way, any code changes that are made will show its result after five seconds. You’ll know if your code change has broken something, or if it works as planned. To achieve that, we’ve chosen Travis (https://travis-ci.org/) a tool that is fully open source and free of use.

Screenshot from 2014-09-24 14:32:06

Within Travis CI, you can actually configure any repository on GitHub that is fully open source. Travis CI will take care of building that repository. Making a .jar file out of it and then releasing that .jar file back to the GitHub repository. The only thing you need to do is to add the plugin to Travis and create a .travis.yml file to enable them. All the repositories currently public under the XebiaLabs community will communicate with GitHub. Currently, we’ve enabled them all. Which means that each time someone does a code change, Travis CI will automatically build the plugin and check if it has compiled it or not, and then run the unit testing on that level free of use.

Notifications via HipChat
Next step is to make sure that each time a build fails, a notification is being sent. This is as easy as adding a travis notification to the .travis.yml file

travis --add notifications.hipchat.rooms

Currently we’re using HipChat within XebiaLabs, but the same way you can also get a notification using email. When a code change is made, all registered users in the HipChat chatroom will be notified. If a code change is not 100 percent correct, an alert will be sent. Also releases are done via Travis CI. By executing travis setup releases you configure within the .travis.yml that each time you set a tag on github, travis will build a new release for you.

That’s it. So by simply adding this Travis YML file, you can configure the whole Travis continuous integration tool, which is going to build all of your community plugins and even send releases back to GitHub itself, so end users can just download the .jar file. They can put them into whatever XebiaLabs XL product they are using, either XL Deploy or XL Release, and then by restarting the tool itself, they can start using the plugin on that level. Users don’t have to worry about the compiled version. They can download the latest version on that level.

There you have it. Easy as pizza.

You want to join or help:


Joris De Winne

About the Author ()

Joris De Winne is a Sales Engineer at XebiaLabs with expertise in Agile and Scrum.