Perforce Adds Slack Support to Helix ALM

Application lifecycle management (ALM) vendor Perforce has added Slack integrations to its flagship Helix ALM product suite. Adding support for Slack to Helix makes sense, as it brings tools to where developers are. Instead of breaking flow, tasks and other issues can be captured, while messages from automated tools elsewhere the build process can be surfaced alongside conversations.

For Perforce, adding Slack support is part of the company’s approach to integration. “It’s ecosystem integration for DevOps at scale,” said Perforce’s Chief Product Officer, Tim Russell.

Helix is a set of tools for managing application lifecycles, and, as such, it can’t stand alone. ALM tooling needs to be able to plug into other applications' APIs to build an appropriate DevOps pipeline. “There are so many approaches to integration,” noted Russell. “We can use APIs, or we can use direct methods.”

But while the methods vary, the aim is the same: “We’re capturing actions,” said Russell.

Perforce’s Slack integration is an example of this approach, he adds: “Where humans are involved, email doesn’t work.”

By integrating at a deep level, Slack can be used as a key tool in capturing different stages in the application development lifecycle. “We even find Slack used as a tool to capture designs and to capture user stories from its history.” There is perhaps a useful side effect here: By formalizing the use of Slack, the risk of the platform being used for non-work purposes is reduced.

Links from Helix ALM are surfaced as items in integrated channels. There’s no need to cut and paste content; it’s automatically displayed along with status information and formatted appropriately. At the same time, responses to conversations about requirements or other Helix items inside Slack are tracked and displayed as comments in Helix. When you’re viewing an item you’re able to see it in the context of team discussions, helping make appropriate decisions.

Slack webhooks are a useful integration point for services like Helix, as they allow its various triggers and notifications into Slack. Formatted data can be encapsulated in a webhook call and displayed in Slack without any additional work.

Integration is very simple, and driven from inside a Slack account. You’ll find an Add to Slack link in the Helix documentation; this feature handles the process of launching a Slack tool that configures and adds a Helix bot into your Slack instance. This bot then runs on a local server in your network, acting as a gateway between the two applications. Inside Helix you’ll need to configure the Helix REST APIs and add a Slack user for the service, to give the bot API access, as well as give an administrator rights over the bot. Once running the bot can be switched to running as a service, so you don’t have to worry about launching it if your server restarts.

Once the bot’s been installed, all you have to do to use it is invite it to a channel. It’s best to keep it in channels that are tied to specific projects and to specific work streams. One other task on the Helix side is to give the bot access to projects. You’ll also need to link user names between the two services, in order to ensure that recorded comments are tied to the right person.

Russell compares Slack integration to the company’s recent acquisition and integration of PRQA’s static analysis tools. Focused on C and C++ and on distributed and embedded systems, the PRQA tooling is intended to bring complex application testing into the source management pipeline and put it in the process as early as possible.

These two approaches, while seemingly quite different, are all part of a larger strategy that considers DevOps a model that needs to scale, with a focus on the process that starts with planning and ends with delivery. “We’re anchored by version control,” Russell said. “We version everything to maintain order.”

It’s an approach that also needs to be balanced by an understanding of the relative DevOps maturity of Perforce’s customers. Some are a lot further along the road than others, so the tooling needs to be adaptable and responsive.

“You need to start where you are and move to more agile processes without having to change tools midstream,” said Russell. “And you can’t have communications bottlenecks. ‘I didn’t see that email' should no longer be an excuse.”