News

Welcome to End Point’s blog

Ongoing observations by End Point people

Spree on Heroku for Development

Yesterday, I worked through some issues to setup and run Spree on Heroku. One of End Point's clients is using Spree for a multi-store solution. We are using the the recently released Spree 0.10.0.beta gem, which includes some significant Spree template and hook changes discussed here and here in addition to other substantial updates and fixes. Our client will be using Heroku for their production server, but our first goal was to work through deployment issues to use Heroku for development.

Since Heroku includes a free offering to be used for development, it's a great option for a quick and dirty setup to run Spree non-locally. I experienced several problems and summarized them below.

Application Changes

1. After a failed attempt to setup the basic Heroku installation described here because of a RubyGems 1.3.6 requirement, I discovered the need for Heroku's bamboo deployment stack, which requires you to declare the gems required for your application. I also found the Spree Heroku extension and reviewed the code, but I wanted to take a more simple approach initially since the extension offers several features that I didn't need. After some testing, I created a .gems file in the main application directory including the contents below to specify the gems required on the Badious Bamboo Heroku stack.

rails -v 2.3.5
highline -v '1.5.1'
authlogic -v '>=2.1.2'
authlogic-oid -v '1.0.4'
activemerchant -v '1.5.1'
activerecord-tableless -v '0.1.0'
less -v '1.2.20'
stringex -v '1.0.3'
chronic -v '0.2.3'
whenever -v '0.3.7'
searchlogic -v '2.3.5'
will_paginate -v '2.3.11'
faker -v '0.3.1'
paperclip -v '>=2.3.1.1'
state_machine -v '0.8.0'

2. The next block I hit was that git submodules are not supported by Heroku, mentioned here. I replaced the git submodules in our application with the Spree extension source code.

3. I also worked through addressing Heroku's read-only filesystem limitation. The setting perform_caching is set to true for a production environment by default in an application running from the Spree gem. In order to run the application for development purposes, perform_caching was set to false in RAILS_APP/config/environments/production.rb:

config.action_controller.perform_caching             = false

Another issue that came up due to the read-only filesystem constraint was that the Spree extensions were attempting to copy files over to the rails application public directory during the application restart, causing the application to die. To address this issue, I removed the public images and stylesheets from the extension directories and verified that these assets were included in the main application public directory.

I also removed the frozen Spree gem extension public files (javascripts, stylesheets and images) to prevent these files from being copied over during application restart. These files were moved to the main application public directory.

4. Finally, I disabled the allow_ssl_in_production to turn SSL off in my development application. This change was made in the extension directory extension_name_extensions.rb file.

AppConfiguration.class_eval do
  preference :allow_ssl_in_production, :boolean, :default => false
end

Obviously, this isn't the preference setting that will be used for the production application, but it works for a quick and dirty Heroku development app. Heroku's SSL options are described here.

Deployment Tips

1. To create a Heroku application running on the Bamboo stack, I ran:

heroku create --stack bamboo-ree-1.8.7 --remote bamboo

2. Since my git repository is hosted on github, I ran the following to push the existing repository to my heroku app:

git push bamboo master

3. To run the Spree database bootstrap (or database reload), I ran the following:

heroku rake db:bootstrap AUTO_ACCEPT=1

As a side note, I ran the command heroku logs several times to review the latest application logs throughout troubleshooting.

Despite the issues noted above, the troubleshooting yielded an application that can be used for development. I also learned more about Heroku configurations that will need to be addressed when moving the project to production, such as SSL setup and multi domain configuration. We'll also need to determine the best option for serving static content, such as using Amazon's S3, which is supported by the Spree Heroku extension mentioned above.

Learn more about End Point's Ruby on Rails Development or Ruby on Rails Ecommerce Services.

8 comments:

Anonymous said...

Can you clarify what you mean when you say "I discovered the need for Heroku's bamboo deployment stack."

I don't see any other mention of that being required to use Spree on Heroku.

Thanks!

Steph Powell said...

Yes, I will clarify: First, I tried to deploy the application and was getting a rubygems 1.3.6 error among other errors. I googled a bit and found some documentation that mentioned Heroku only supports up to rubygems 1.3.5. At the same time, my client had emailed the Heroku support team with the error and they responded by recommending using the bamboo stack for applications requiring >1.3.5 rubygems. Note that this blog article is about running Spree 0.10.*. Previous versions of Spree do not depend on rubygems 1.3.6.

viatropos said...

Thanks a lot man, this worked great.

Егор Доровских said...

pls help me. i trying to start spree on virtual hosting(hot heroku). Now i found problem that some files of stylesheets do not read in admin panel of production env. and new product pictures can not read too. if i change all folders in public to 755 all working. how to change this?

Steph Powell said...

Hi,

I'd recommend emailing the spree-user google group for your questions and concerns. You'll have a much larger audience there.

Thanks!

paulcc said...

Hi Steph

excellent post, as always.

here's some more info:

git submodules - it is possible to retain git support for submodules in development work yet have them still usable in heroku. The trick is to .gitignore the .git directories in the submodules; hence inside the submodule it looks like the normal extension repo, and outside the submodule it looks like a bunch of extra files in the main repo. This really works well! See http://stackoverflow.com/questions/918768/are-git-submodules-the-only-safe-way-to-have-working-copies-within-working-copies/918927#918927

file assets Similar trick: override the fileutilz library to be a no-op when running on heroku. So it means that assets still come from extensions etc into public/ when developing, and then can be tracked in the main repo

William said...

Are there any updates to this for Spree 0.4? Do these steps still apply?

Steph Skardal said...

There are most certainly changes to this procedure for Spree 0.40. I'm not sure if the Spree Heroku extension has been upgraded to work with Spree 0.30 and 0.40 (both run on Rails 3). Much of the architecture for Spree 0.30 and 0.40 is different from previous versions & I haven't looked into the extension since the release of these recent versions of Spree. Off the top of my head, I think that dealing with gems may be easier with the introduction of Bundler. It may also be easier to run on Ruby 1.8.7. Finally, you'll still have to create workarounds to deal with Heroku's read-only file system.