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).
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.
Starting outThe 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:
- 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.
- 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?
- 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.
Integration ImprovementsSo, 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 FirstsTo 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