Today I had to change a belongs_to associate to an has_and_belongs_to_many in a Rails project I’m currently working on. Not that hard you would say, but there were some catches for deploying/migrating these changes to the production environment.

In this post I’d like to explain how to achieve this without having to do multiple deployments of your model to maintain a consistent database schema and model.

As a follow-up of my previous post I want to explain how to get Sidekiq to work on Heroku with a Redis To Go Nano instance.

Because the Nano instance has some connection limitation you have to make some config changes so you won’t get ERR max number of clients reached error messages.

In this post I’d like to show you guys how to deploy your Rails application to Heroku with a Sidekiq worker that only gets initiated when there are tasks in the queue to process.

Our goal is to start a worker when a task is added to the queue and to destroy the worker after its done processing the queue tasks. This will result in a much lower bill at the end of the month because the worker doesn’t have to be up the whole month.