Having a staging environment to verify changes adds an extra measure of confidence to each deployment. Git is the primary means for deploying apps to Heroku. For Heroku, a staging environment corresponds to another app. For Git, it is just a branch.

Thomas Balthazar has written a full outline of how to deploy multiple environments on Heroku and still host your code on GitHub. With the Heroku and GitHub repos thus configured, our local repo has three branches:

• Working
• Staging
• Production (master)

Why do we use Git?

We build and test all changes in the Working branch before merging with the Production master. Our workflow to deploy a tested change from Working through Staging to Production:

# standing in /rails_app_root

git checkout -b working

# after committing a change

git status

# nothing to commit (working directory clean)

git checkout staging

git merge working

# 'see' Fast forward

git push heroku_staging staging:master

heroku maintenance:off —app staging_app_name

# exercise the staging app to verify change

heroku maintenance:on —app staging_app_name

git push  # to GitHub

git checkout master

git merge staging

# 'see' Fast forward

heroku maintenance:on —app production_app_name

git push heroku_production

heroku maintenance:off —app production_app_name

git push  # to GitHub

git checkout working

# go forth and make more changes

Witness the ease with which a local Git repo operates with remotes on GitHub and Heroku. Those who have not yet tried Git may not know what they have been missing.

Some months ago we adopted delayed_job as our asynchronous background processor. In Realized-app several tasks, particularly tax lot setup, benefit from background processing.

Taking the advice from this blog post on GitHub, we reduced the coupling between models and the message queue by placing the background methods in lib/msg_queue.rb.

module MsgQueue

  class UserActivationConfirm < Struct.new(:user_id)

    def perform

      user = User.find(user_id)

      user.activation_confirmation_email

    end

    . . .

We create the corresponding delayed job in models/user.rb.

class User

  def activation_confirmation_mq

    mq = MsgQueue::UserActivationConfirm.new(id)

    Delayed::Job.enqueue(mq)

  end

end

The call to Job#enqueue remains within each model to allow for passing a priority parameter, should that be needed.

Deployment on Heroku

Heroku began limited support for delayed_job in July. Yesterday Heroku broadened that support with a new feature that provides for multiple delayed_job workers per app. That capability sealed our decision to deploy, at least initially, on Heroku.