Systems | Development | Analytics | API | Testing

Nearly eight years ago, Cory and I started on a journey to help developers build software quickly and painlessly. As software developers ourselves, we had felt the pain of being afraid to ship and spending late nights tracking down bugs. In 2013, we launched Rollbar into the world so that developers could build software faster, shipping often without fear. These days, lots of people talk about continuous delivery, and nearly all of them focus on automating releases.

At Rollbar we love workflow automation. With our new Notifications API, you can automate setting up of custom notification rules for all your Rollbar projects. As more of our customers switch to microservices, we wanted to build a programmatic way to set up these rules for multiple projects or services in just a few seconds, without having to go to the UI.

At Rollbar, we care about reducing the time it takes developers to find and fix errors. This is why we’re making our integration with GitHub even stronger to provide more context around errors and reduce the mean time it takes to resolve them MTTR. Last year, we launched Code Context to show additional lines of code within each frame of the stack trace, reducing the back and forth between GitHub and Rollbar.

In the first post of this series, we looked at the state of your organization, how to tell if Microservices are right for you, and wrapped up with a few challenges this architecture brings to the table. In this article, we will look at organizational changes that will help you adopt a Microservice architecture. Additionally, we will touch on topics like how to bring change to your organization, how to embrace the primacy effect, and why you should embrace cross-functional teams.