ChatOps (Slack integration)
Last updated 17 January 2018
Table of Contents
How it works
Heroku ChatOps uses the power of Heroku Pipelines to bring a collaborative deploy workflow to Slack.
Heroku ChatOps also provides some additional features over a traditional Heroku deploy. When you deploy using Heroku ChatOps, we’ll check your required status checks on GitHub to ensure that you’re only deploying code with passing tests. We’ll also notify GitHub that your code has been deployed so that your pull requests will have a record of successful or failed deploys.
Installation and setup of Heroku ChatOps requires Slack permissions to add and approve apps. More information on Slack app management is available here.
Since Heroku ChatOps is built around pipelines, your applications need to be in a pipeline to take advantage of ChatOps features.
Click here to get started:
Setup your account
To use Heroku ChatOps, you need to sign in to Heroku and GitHub. Any permission you have in ChatOps comes directly from the permissions you have in Heroku and GitHub.
If you’re either the owner or a collaborator on an app, you have all the required permissions to use ChatOps on that app.
If you’re either the owner or a collaborator on the GitHub repository that is linked to your pipeline, you have all the required permissions to use ChatOps on that pipeline.
Deploying code to an app
There are two ways to deploy your code to an app using Heroku ChatOps, the deployment flow or Pipeline promotions. With both deploys and promotions, we’ll use Slack threads to provide updates along the way, from when the deployment or promotion starts, to when your last dyno has finished restarting.
Each step is saved in a thread:
/h deploy PIPELINE_NAME to STAGE_NAME
Deploying a specific branch
/h deploy PIPELINE_NAME/BRANCH_NAME to STAGE_NAME
Deploying when you have multiple apps in a stage
/h deploy PIPELINE_NAME to STAGE_NAME/APP_NAME
Forcing a deployment even if pre-deploy checks are failing
If you try to deploy an app when a required status check is failing , it will refuse to deploy.
You need to force the deployment using
/h deploy! PIPELINE_NAME to STAGE_NAME
Pipeline promotions have a few additional benefits over manual deployment workflows. For example, they ensure that a release to production contains the exact same compiled code as a release to staging, and promotions will also be faster than recompiling the slug.
By default, it will promote from staging to production.
/h promote PIPELINE_NAME
You can also specify an upstream stage. It will promote from the specific upstream stage to production.
/h promote PIPELINE_NAME from UPSTREAM_STAGE
Multiple apps in a stage
If you have multiple apps in your upstream stage, you’ll need to specify a source app to promote from.
/h promote PIPELINE_NAME from UPSTREAM_STAGE/APP_NAME to DOWNSTREAM_STAGE
If you have multiple apps in the downstream stage, you’ll need to specify which downstream app you’d like to promote to.
/h promote PIPELINE_NAME from UPSTREAM_STAGE/APP_NAME to DOWNSTREAM_STAGE/APP_NAME
Or you have multiple apps in the downstream stage, you can also specify a list of target app separated by a comma.
/h promote PIPELINE_NAME from UPSTREAM_STAGE/APP_NAME to DOWNSTREAM_STAGE/APP_NAME,APP_NAME2
Or another way to promote to multiple apps in a downstream stage is by specifying that you’d like to promote to all downstream apps.
/h promote PIPELINE_NAME from UPSTREAM_STAGE/APP_NAME to DOWNSTREAM_STAGE/all
Forcing a promotion even if pre-deploy checks are failing
If you try to promote an app without having the required contexts, it will refuse to promote. You need to force the promotion to bypass the check.
/h promote! PIPELINE_NAME
Viewing latest releases
You can view the latest code deploys and configuration changes for the default stage.
Releases for production stage
/h releases PIPELINE_NAME
Releases for a specific stage
You can also specify a stage, like
/h releases PIPELINE_NAME in STAGE_NAME
/h info PIPELINE_NAME
You can obtain a list of deployable pipelines.
Connecting CI and other pipeline events to your Slack
If you’d like to be notified about pipeline events, like a pull request opening, a Heroku dashboard deploy or promotion occuring, or your CI tests passing, you can route notifications to any public Slack channel.
Route pipeline notifications to a channel
/h route PIPELINE_NAME to #CHANNEL_NAME
Once you route your pipeline notifications to your channel, you’ll start receiving notifications. Here’s an example of a CI notification:
Pipeline notification routing currently only supports a single Slack channel. Pipeline events initiated from the CLI are not displayed.
Stop routing Pipeline’s notifications to a channel
You can also disable notifications for a pipeline.
/h route:disable PIPELINE_NAME
List Pipelines routed to a channel
Threshold Alert notification routing
Threshold Alerts allow you to monitor application health by sending a notification if the p95 response time or error rate for your app’s web dynos exceeds your configured threshold setting for a specified period of time. Once you have a pipeline routed, you’ll also receive Threshold Alert notifications for any alerts configured for pipeline apps.
Alert monitors are configurable in Application Metrics.
Within Slack you’ll see receive a notification for the alert and when app health returns to an acceptable state. Clicking on the message links will take you to Application Metrics for further investigation or to adjust alert threshold settings.
ChatOps does not support routing notifications to private Slack channels or teams using Github Enterprise.