Challenge 2: A Heroku Procfile — Solution

web: bundle exec puma -C config/puma.rb
release: rails db:migrate
worker: bundle exec sidekiq

=begin
Notes:
- web is the process Heroku routes actual HTTP traffic to -- Puma, started
  with the app's own config/puma.rb, matching how every request/response
  example throughout this course has ultimately been served.
- release runs once per deploy, before traffic is switched over to the new
  code -- rails db:migrate here means any migration written since the last
  deploy (rails1-5's Active Record migrations) is applied automatically,
  rather than someone having to remember to run it by hand after every
  push.
- worker runs continuously, completely separately from the web process --
  this is the Sidekiq process rails2-4 needs to actually execute jobs
  pulled off the Redis-backed queue; without it, jobs enqueued via
  perform_later would sit in the queue forever, never running.
- All three process types are declared side by side in one file, but
  Heroku scales and restarts each independently -- a spike in job volume
  can scale up worker dynos without touching web at all.
=end