The process of developing software takes place in tools well beyond a developer’s IDE. Often it involves a number of specialized tools to manage all sorts of aspects of planning, design, implementation, and testing. By enabling information to flow seamlessly between each tool, integration can help enable this whole process to work a little smoother.
Here at Tasktop, we are building an integration platform that enables organizations to configure integrations from well-defined concepts. It allows one to define define endpoints (eg a JIRA repository and an HP repository), and configure integrations (eg Defect Unification Synchronization) to flow information between the endpoints.
Of course, we use this platform to integrate our own toolchain. We use Tasktop Sync to move features from TargetProcess into stories in JIRA. We use Tasktop Data to maintain various reports on our development process. And we rely on Tasktop Gateway integrations to link to Gerrit reviews from JIRA tasks. The individual tools are each great for one aspect of the software development process, and the integrations do wonders for enabling collaboration and traceability across the tools.
Lately, we’ve been using another popular tool: Slack. At Tasktop our teams are distributed, with Product in Austin, and Engineering in Vancouver, Germany, and Poland. A chat tool like Slack helps facilitate real-time communication, which is a key part of our development process. We set out to explore ways to improve our process by integrating chat with other parts of our toolchain.
Putting Chat in the Toolchain
Group chats, or channels, are quickly becoming a common piece of our software development toolchain. We use them to facilitate synchronous communication across our distributed teams. Some channels act like a remote water cooler: a place to drop in and socialize. Most teams have their own channel which is a good place to ask questions and discuss solutions.
One useful pattern we’ve found is to move information from another tool into a channel: “I finally fixed that Defect!”, “My task is ready for Done Review”, or “New Code Red”. We find these types of notifications useful; they provide insight into progress and next steps.
To manually integrate these tools requires effort. Firstly, we must be conscious of the team’s rules about what changes to broadcast. If we remember that we should broadcast, and recognize that a change meets the criteria we set out for broadcast, then we must next switch tools to the chat and summarize the change. Interruptions, and redundant data entry, no matter how brief, can have a disproportionate impact on the amount of real work one is able to do. Hence the case for an automated notification mechanism that integrates our task tracking tools with our chat tool.
And so our first crack at a Slack integration was a simple idea: propagate changes in other parts of the toolchain to a Slack channel. An important part of making this type of integration successful is to ensure that the right amount information is flowing. In particular, we want to avoid “spammy” notifications that just cause distractions. This means the teams must be enabled to tune exactly what is flowing based on the process and patterns that work for them.
Building on this new type of integration on our Integration platform was a no-brainer. It allows us to integrate with any of the (many) systems we already support. Just as important, it allows us to leverage the common terminology (and ultimately UX) that we are developing to support a vast integration landscape.
Point, Click, and Send to #your-channel
With a surprisingly little amount of work, we created a (alpha-version) Slack integration on the Tasktop platform.
First, we leverage the existing models concept in the Tasktop platform. This allows users to build up their own models with a normalized view of the data. So users can create a model called a “Slack Artifact” which contains the fields in which they are interested. The platform can then automagically provide Collections from various repositories (e.g., JIRA and TargetProcess) that use this user-defined model.
The next piece of the puzzle is configuring the other endpoint of the integration: a Slack Collection that allows us to push a view of the the model to Slack via a webhook.
Finally, we provide a new integration style called a Chat Notification Integration. This integration pulls in artifacts from any of the systems we already integrate with, and sends the results to a Slack Collection.
With these abstractions in place, it’s a simple point and click to to get change notifications into a Slack channel.
Controlling and tuning the information flow happens in two ways that will be familiar to existing users of the platform. First, we can choose what bits of information we want to flow. For our team, we wanted updates as tasks get assigned and their status changes, so we add those to a simple model, but didn’t include other properties like description since broadcasting every change would be too spammy.
Additionally, users can use the filtering mechanism to further limit the flow. For example, one team at Tasktop wanted notifications only on tasks that are ready for done review. This was simple to configure with the existing filtering concept baked into the platform.
We’ve been running with these notifications for a few weeks, and we are really liking them. It’s a nice way to get a sense of what people are working on. Because the configuration is so easy, other teams are enabled to start trying out with little overhead.
Now we see a steady stream of relevant updates flowing into our channel. We don’t have to add a comment to tell teh team that we closed that monster of a story, but sometimes it’s fun to add a celebratory response.
More Integration with Chat
This post has described a simple chat integration: notifications that push information into a conversation. We’ve shown how the Tasktop platform is well positioned to serve as a hub for these sorts of integrations. And we’ve argued that integrating chat with the rest of an organization’s toolchain can have benefits by saving the cost of the context/tool switch.
As we start to consider the next steps, we are excited by the potential to enable our chatbot to both flow information out of slack as well as answer people’s questions about the rest of the toolchain.
For example, suppose I wanted to know what my coworker Sam was working on. Naturally, I could just ask Sam on Slack directly — but perhaps at that moment he’s offline, too busy to answer, or I just don’t want to interrupt him. A manual approach would be to look up what recent tasks he has updated on JIRA, or Gerrit, and so on. But this is a time-consuming process that involves switching between a number of different tools. Rather, it would be great if we could avoid interruption and context-switching and instead allow Taskbot to listen and answer for us.
Stay tuned for part two where we follow up on these ideas!
Blog by Senior Software Engineer, Clint Morgan, and Sam Creed, a Masters student at UBC, working with Tasktop as part of a project to improve the integration of software traceability with everyday workflow.