Wercker Steps Use Case: Rollbar-Notify

Wercker is a Docker-Native CI/CD Automation platform for Kubernetes & Microservice Deployments

Zachary Flower
Zachary Flower
March 7, 2018

I’m a huge fan of the DevOps methodology, but it often suffers from information overload. With automation comes notifications, and if you’re not careful, these notifications can quickly become overwhelming. And after a while, it doesn’t matter how important a notification is—You eventually stop seeing them altogether.

As a result of monitoring apathy, I have grown to love passive metric methods. Basic dashboards, subtle badges, minimal toasts…These are the things that give you the information you need without getting in your way.


Enter Rollbar

One great example of a passive metric is Rollbar’s deployment tagging. If you are unfamiliar with Rollbar, it is an error tracking service that provides real-time alerting and debugging tools for production applications. While aggregating exception and error metrics in one central location is valuable in and of itself, it can be difficult to keep everything straight as you deploy code to fix existing issues.

This is where Rollbar’s deployment tagging comes into play. To help contextualize errors between deployments, Rollbar provides an API that you can use to mark when new code has been deployed. This allows you to finely track what errors are happening before and after releases, and helps keep track of what issues have yet to be fixed.

Image 2017-12-18 at 2.54.45 pm.png


Rollbar + Wercker

Now, this is an awesome feature, but how exactly do we integrate it with our specific deployment method? This is where the rollbar-notify Wercker Step comes into play. Once configured, we can send deploy notifications to Rollbar from directly within our existing CI/CD pipeline, allowing us to track important data with minimal overhead.

Before we can link Wercker and Rollbar, however, we first must take note of our Rollbar Access Token. To get this, head on over to the settings for a Rollbar project, add a new “write” access token, and take note of the generated value. We will need this to make calls to Rollbar’s API from within Wercker.


Image 2017-12-18 at 2.56.25 pm.png

Next, we need to take that access token and add it as an environment variable within our Wercker project. This is an important step, as it keeps our Rollbar access token in a safe place and outside of our source code repository.


Image 2017-12-18 at 2.57.25 pm.png

Now that we’ve set up our Rollbar access tokens, we can now tell Wercker how to send deploy notifications during our build process. Thanks to Wercker Steps, this process is incredibly straightforward. All that is required is to open up your wercker.yml file and add the rollbar-notify step to the after-steps directive of your deploy pipeline:



   - akelmanson/rollbar-notify:

     access-token: $ROLLBAR_ACCESS_TOKEN

After the standard deployment script is run, the rollbar-notify step will be run using the access token we defined earlier. While it may seem simplistic at first glance, there are some additional settings that can be used to more thoroughly integrate your Wercker and Rollbar accounts.


Taking It Further

The most important parameter available, second to the Rollbar access token, is the environment property. This parameter allows us to tell Rollbar exactly which environment was deployed. If you are using Rollbar to monitor multiple environments (such as staging and production), then this allows you to identify which environment was actually changed on deploy.

Image 2017-12-18 at 2.59.17 pm.png

The next parameter available to change is the username of the user who actually deployed the code. In Git, blame is a popular command for identifying who changed what and when. This is a great way to not only hold people accountable, but also keep track of who might have the best understanding of a particular deploy. While this parameter defaults to the Wercker user who triggered the deploy, you have the ability to update it to reflect information that might make more sense for your organization, such as an email address, Slack username, or employee number.

Finally, the on parameter can be used to tell Wercker when to notify Rollbar of a deployment. This defaults to passed, which means to only notify Rollbar when the build process has passed. However, if you would like to notify Rollbar of deployments on every build, regardless of status, then it can be changed to always.


Next Steps

While this is a great example of passive notifications in an otherwise noisy DevOps world, it is just one of potentially many. If you don’t use Rollbar, or have issues with overly aggressive monitoring platforms, The Wercker Steps Registry is an excellent place to start the process of tuning and slimming down the amount of fluff in your communication channels.


About the Author

Zachary Flower is a freelance web developer, writer, and polymath. He has an eye for simplicity and usability, and strives to build products with both the end user and business goals in mind. From building projects for the NSA to creating features for companies like Name.com and Buffer, Zach has always taken a strong stand against needlessly reinventing the wheel, often advocating for the use of well established third-party and open source services and solutions to improve the efficiency and reliability of a development project.    


Topics: Tutorials