Sharing structured data

XML Magazine

Subscribe to XML Magazine: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get XML Magazine: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


XML Authors: Peter Silva, Stackify Blog, Mamoon Yunus, Progress Blog, XebiaLabs Blog

Related Topics: Intel XML, XML Magazine

Blog Feed Post

A Day of Firsts: Adventures with XebiaLabs’ XL Release

Release Management tools are not something I normally look at since I am more on the development side of things than on the release and operations side. With the advent of DevOps, the communication gap between both silos is closing, and that is certainly true within my company, Perforce, where I suddenly find myself responsible for the build and release of my own tools (and that is A Good Thing).

https://i0.wp.com/blog.xebialabs.com/wp-content/uploads/2016/09/Drawing-... 300w, https://i0.wp.com/blog.xebialabs.com/wp-content/uploads/2016/09/Drawing-... 768w" sizes="(max-width: 269px) 100vw, 269px" data-recalc-dims="1" />

But I wear many hats these days (avoid me in a dark alleyway), and one of these hats is that of a technical marketer, which encourages me to look beyond my own realm and see what other tools have to offer. One of the tools I noticed was XebiaLabs’ XL Release, which piqued my interest since I have seen them a few times at tradeshows, often in a booth right next to Perforce. I recently found out that XL Release offers an integration to Perforce Helix.

Why Is This Important?

Perforce Helix is the version management tool of choice for a lot of the core infrastructure of the technology we take for granted, but it does not live in a world on its own: we don’t provide the whole stack from requirement to delivery (although we are starting to fill out some of the gaps (for example with Helix ALM). Instead, our customers rely on integrations with tools like build systems or release management, and it is essential that we offer these integrations and make it as easy as possible for third parties to build their own integrations as well. This is why we have a rich set of APIs from C++, Java, Python, to .Net that make accessing Perforce Helix as simple as possible.

One of the mantras of DevOps is automate, automate, automate to avoid human errors associated with manual configuration and processes. This applies to the release process as well. If I need to inform a release engineer directly or via email every time a new release is available, there is a higher likelihood that releases will be missed or information will be miscommunicated. Leveraging a tight integration between release automation from XebiaLabs’ XL Release and an enterprise version control system such as Perforce Helix, I (and others) can avoid critical issues by establishing triggered communications around release readiness.

https://i1.wp.com/blog.xebialabs.com/wp-content/uploads/2017/02/Screen-S... 234w" sizes="(max-width: 165px) 100vw, 165px" data-recalc-dims="1" />

WHITE PAPER

Release Pipeline Orchestration 

An Essential Practice for Continuous Delivery at Enterprise Scale

Learn how release pipeline orchestration solutions help even the largest of enterprises efficiently manage and optimize their software release pipelines.

 

Starting out

The idea of the integration is very simple: poll a repository for any relevant changes and trigger a potential release. To do this, you first need to configure a connection and then define a set of triggers as part of a release template that use the connection and create a release from the change.

So, when I heard that “Perforce Helix was integrated with XebiaLabs” I decided to take a closer look to see how effective the existing integration worked and determine if I should/could make any improvements, for example:

  1. Adding a connection test button to see if the supplied credentials work. The XL Release documentation taught me that a test ability can be easily added.
  2. Filtering the changes to be monitored. Perforce Helix is different from other repositories: there is typically only one server holding all files from all projects (a “Single Source of Truth”) and triggering a release for every change going into the server would be a bit… overkill?
  3. Cleaning up additional fields in the Perforce Helix shared configuration page related to HTTP Proxy configurations, which are not needed since the Perforce Helix network protocol is not based on HTTP.

I decided to dig in and find out if I could extend the tool. I was able to access the integration project in GitHub, so I forked and cloned the project and tried to understand its implementation. Turns out that XL Release is written in Java and uses Jython for scripting plugins. Although I am known as the Python guy within Perforce and have been using Java for many years, I had never actually laid a hand on Jython (Python script running in a JVM with access to Java classes), which turned out to be very simple indeed.

The integration uses P4Java, which I hadn’t used beyond simple demonstration scripts, so this was another first for me. Writing a simple test script for the “test” button was easy enough, changing the connection interface was an easy rewrite of an XML file, and soon I was up and running. I must say the XL Release architecture is very simple to extend and the interfaces are very clean. Good job XebiaLabs!

Integration Improvements

So, I was able to enhance the integration. It now sports an optional “workspace” field on the trigger page that lets users specify an existing workspace, the view of which will be used as the filter. For example, if I create a workspace called xl_release with the following view:

                  //build/scripts/...                //xl_release/scripts/...

                  //build/libraries/...              //xl_release/libraries/...

Then, only changes that affect files under the two paths //build/scripts or //build/libraries will trigger a release.

With these improvements, XebiaLabs users can now test out their connection to Perforce Helix server configuring triggers that only fire on filtered changes, thereby avoiding clutter.

Having got everything working to my liking and after updating the documentation, I embarked on my next adventure: filing a pull request on GitHub. Although I have had a GitHub account for years and have contributed to Open Source projects on other sites, I have never actually worked with someone via GitHub. Turns out the process was quite painless, even when XebiaLabs came back with a query, which required an update to my original request. If you look at the source code, you can see how little code is required to build a functional integration.

A Day of Firsts

To sum it up, it was a day of firsts:

  • First time I used XL Release or any other release management tool
  • First time I used Jython
  • First time I used P4Java in a real project (beyond simple tests)
  • First time I built (or extended) an integration into anything but an editor (See my adventures writing a plugin using Notepad++ here.)
  • First time I filed a pull request
  • First time I had a pull request accepted

Ever felt like trying something new? Have a look and see what Perforce has to offer.

Happy hacking!

Editors note: This post first appeared on the Perforce blog here

The post A Day of Firsts: Adventures with XebiaLabs’ XL Release appeared first on XebiaLabs Blog.

Read the original blog entry...

More Stories By XebiaLabs Blog

XebiaLabs is the technology leader for automation software for DevOps and Continuous Delivery. It focuses on helping companies accelerate the delivery of new software in the most efficient manner. Its products are simple to use, quick to implement, and provide robust enterprise technology.