The Slack Integration

About a year ago, my group at Redgate Software adopted Slack as a way of communicating with each other. Slack has become very popular with development teams, and is used extensively in many companies, including my own. At first I liked this tool, which allows some real time communications, but also some tagging and notifications if someone messages you. However, over time, I find it less useful. Perhaps the seven hour time difference accounts for some of that.

However plenty of people have found various ways to integrate Slack into their development process. Everything from build failures to successful deployments to mentions on Twitter. I’m not sure of the value of these myself, but I can understand that grabbing messages and centralizing them in a channel can provide value. Personally I still prefer to work through email, which gives me a nice, asynchronous, disconnected, comfortable tool.

The other day someone asked me if we would think about integrating parts of SQLServerCentral with Slack. I wasn’t sure there was value, but then I thought, perhaps some people would like a channel with interesting or hot threads in the forums, or mentions of articles. Certainly many people like different mediums of communication, so why not Slack?

It wouldn’t be for me, but I do wonder how many of you are using Slack and would want to to add in a new channel. Or a few channels. Maybe you’d like one with the Question of the Day and interesting notes from the discussion. Since Slack can work across companies and accounts, we certainly could open things up to you.

Let us know today what you think of Slack and would you like any integration with the tool. How would you use it?

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 2.4MB) podcast or subscribe to the feed at iTunes and LibSyn.

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial and tagged . Bookmark the permalink.

3 Responses to The Slack Integration

  1. I’m using slack with 5 different teams. My “core” team, the one which is involved in agile development of a product, is using it with the following integrations:
    – VSTS for builds outcome
    – PRTG for alerts on PRTG monitoring tool of our, let’s say, production environments

    The second team is using slack for community topics. We’ve integrated a poll system (a simple bot) for managing polls and surveys. Cool!

    The third team is a team which is involved on an education project (I’m applying slack in a school project, called Agile@School). We’re integrating a planning poker bot and giphy for making the cooperation more funny.

    The fourth is heavily using dropbox and google drive for sharing and the fifth one is using github integration.

    I really love slack, it’s quick, comfortable and the performances are impressive. And the phone app (also windows) let me to have everything in a centralized point. I’m using it for about a year, and I cannot live without it in my devlife. We’re automating almost all the processes (dev, deploy, alerting, etc.) and I really need it working as team leader.

  2. way0utwest says:

    Interesting. Do you check all of those regularly? Sporadically for some?

    I struggle with the overwhelming nature of all the channels (we have 200+ at Redgate) And the noiseness of some. Many times there’s almost nothing of value to me.

    • We’ve got 122 opened channels and more than two hundreds archived. Actually we’re working this way (with core team and VSTS):
      – one channel, with prefix ISH for each issue (this channels will become potentially an implementation). For instance, ish_deadlocks is the channel for discussing about sql deadlocks and how to resolve them. If an implementation is found, a PBI on VSTS will be added with the name “p-nnnnn-implem” (for example “p-33445-changequery”).
      – one channel per PBI on VSTS with the format p-nnnnn-topic
      – one channel per EPIC with the name of the topic
      – one channel per BUG on VSTS with the format b-nnnnn-topic
      – “junk” channels, like #random, #general, #nameofthecompany, #aphorisms, etc.

      each channel is linked to the related http link of the PBI, BUG, EPIC and it has a short description in the “topic” section of the channel. They’re all public, private channels are just for discussing about private company topics.

      when the definition of done is reached on PBI and BUG, the related channels are closed and archived. This allows us to have always a small timeframe of channels. We’ve changed also the policies of notifications, and we’ve set the rule “if you make noise, you need attention”. It was not simple, but now all the team members knows when to use @here and @channel and it works very good. We’ve designed processes and the expected behaviors are written in another channel, which is called #sprint-metrics. The same is for the kb of the team. A channel called #knowledge-base keeps all the basics and the welcome kits for developers, also with a set of wiki (wordpress) links.

      Then, we’ve special channels for integration, like “#prtg-sql-alerts-customer” (for each customer which uses PRTG) and “#vsts-build-failed”.

      Again, the team rules channels, like #alm-team-mngmt” and the ceremonies based channels, like “#sprint-review”, “#sprint-retrospective”, “#sprint-definition”, etc.
      Since the process was well “written”, now, I can say that my team is working with that without any problems. That said, it was a big investment in the past for learning curves, but now is written in the wiki and channels, so.. we have a process 🙂

Comments are closed.