Using Slack apps to drive development productivity at USA TODAY NETWORK
Slack + Github = Emoji Driven Workflows
Most companies using GitHub with multiple development teams sharing the same repository use pull requests (PRs) to coordinate their changes. We had some issues with that, though, including:
- PRs getting forgotten about or lost in Slack.
- Old branches weren’t cleaned up after they were merged.
- Developers weren’t notified (in Slack) when changes had been requested.
- Other team members would open PRs that had already been merged.
- JIRA ticket information included the specs the Pull Request should meet, but you had to load another system to check those requirements.
So the Platform Engineering team at USA TODAY NETWORK developed a unique way of communicating the status of PRs, info about the PR and cleaning up after ourselves.
From the developer’s perspective, how does this work?
I take a ticket from the backlog, do my development on some awesome new feature and now it’s time to open a pull request for those changes.
The title of my pull request should include the JIRA ticket number: PROJ-1234 — Some New Feature Set, and I should then be able to open the PR. This is when the first feature of PR Manager comes in. Based on the ticket numbers in the title of the pull request, PR Manager posts the ticket’s information.
NOTE: This also works for multiple linked tickets, so any ticket that is being addressed in your PRs can be linked and posted as well.
Once my PR is ready for someone else on my team to review, it’s time to post it to Slack. Each of our teams have channels for pull requests. Ours is #dev-solutions-pr. In this example, I would post the PR link to that channel:
Notice that the PR’s link immediately got expanded, revealing additional information about the PR.
Now we wait for a developer to pick up the pull request.
👀! Someone has assigned the pull request to themselves!
But uh-oh! Looks like someone has requested changes. I can make the necessary changes, push them and let the reviewer know. Once someone approves my pull request, I’ll see the 👍 emoji.
At this point, either I can merge my own PR or the person that approved my PR will merge it for me. Either way, you’ll see the merged emoji get posted to your pull request, letting other developers know this has already been reviewed and merged.
Do you have developers who forget to delete their branches after merges? We do!
PR manager also takes care of deleting old branches once they have been merged into the master branch. This keeps our repo clean of old branches.
Have a different workflow that you want to keep old branches around? No worries. Developers can add ?branchDeletion=false to their webhook and PR manager will not try to delete the branch for you.
What about high visibility repositories?
We have some repositories that affect multiple teams and PR manager helps us keep teams in the loop for incoming changes, even across Slack channels.
As you configure PR manager for your repository, you have the option to enable the slackNotify feature which takes the following information: Incoming slack webhook URL, array of channels to post to and array of what actions to post on (“opened”, “closed”, “merged”).
Notice from the screenshot that we post the user that took the action, what repository the pull request is on and what action was taken.
So what happens when no one looks at my PR?
PR manager has a built in “nag” feature that reminds teams every two hours if a PR that needs a review isn’t merged. It excludes nights and weekends, of course!
What if I want to know what my team needs reviewed?
Our Slack application also implements a slash command in Slack /PR {state} {team} which will return the PRs for your team in that given state.
What kind of metrics can I see about my teams because of this?
Our team leverages NewRelic for application metrics and monitoring. Because of this, we are able to set up an insights dashboard in NewRelic that shows us who is using our PR manager and how. Things you can see through our dashboard include:
- Top 10 most active repos
- Top merging users
- Team average merge times
- Actions taken per team
How it all works
Developers add a secure github webhook to their repositories and send PR manager pull request related events.
When a new PR is opened, that PR’s information is stored in our database and now lives within the PR manager life cycle.
Now that we have the PR’s information in the database, our Slack application can find the PR’s information by the PR’s URL. When a user posts a message to Slack saying they want to have a PR reviewed, PR manager gets additional information about the PR, expands the link provided and updates the state of the PR in the database to readyForReview.
Other actions that cause state change:
- User approves pull request — approved
- User requested changes — changesRequested
- PR closed — closed
- PR merged — merged
Underlying technologies:
- The application is written using go.
- We leverage the gin framework, and the nlopes/slack and go-github packages.
- Deployed on GKE, using helm.
- Application configurations from consul.
- Secret storage using vault.
- Apigee api gateway security.
- NewRelic for metrics and monitoring.
What difference has it made for the USA TODAY NETWORK?
Our developers love PR manager because they save time by not attempting to review PRs that have already been merged. It cleans up their stale, merged branches, and notifies them when someone wants them to make changes. They love the reminder feature that keeps their PRs from being lost in the Slack abyss and they have applied it to nearly 300 repositories.
The team continues to add new functionality to this process and has future plans to add things like status checks notification and notifying reviewers who requested changes, once the changes are completed.
Easter egg!
With remote employees across the U.S. — including Ohio and Florida — our engineers have played a game of “guess who” between these states’ news articles. Leveraging the same technology stack, we developed a fun bot that allows our engineers to vote on a story by reacting with either the :florida: or :ohio: emoji.
To initiate an Ohio-vs-Florida post, the user types /ovf in the channel they wish to post the challenge to. Leveraging Slack’s dialog feature, we present the user with a form to fill out all of the information about the story.
Once the user submits the challenge, the bot automatically posts the challenge’s summary and how long users have to vote, along with the :florida: and :ohio: emojis to kick off the voting.
Users have the specified amount of time to vote. After that time has passed, the winners are automatically announced.
We try to keep things fun on the Platform Engineering team and we try to think how we can leverage technology to make this a better place to work, have fun, and build good working relationships.
