Remove Heroku from README

[neilmiddleton]

Heroku no longer recommend using Asset Sync for managing assets. This is because:

• It extends out the build process time, frequently causing timeouts
• Requires use of labs features
• Doesn't work with the new releases API

As such the asset sync article on Devcenter has been replaced with "Using Amazon CloudFront CDN with Rails"

Ideally, we don't want to encourage newcomers to Heroku to use this as it invariably ends up with problems. Therefore, could we remove the Heroku-ness from the README? Whilst asset_sync is useful for others, it's no ideal for Heroku customers.

[Breefield]

Interesting @neilmiddleton, thanks for the suggestion + link to new docs.
Seems like rather than just removing the Heroku portion this could be a good opportunity to include the above link in the asset_sync docs so as to point devs in the correct direction.

I agree though, I have personally found asset_sync to be somewhat complicated and temperamental when used with Heroku. Haven't tried CloudFront yet, but I'd like to use an actual CDN instead of S3.

[neilmiddleton]

Sure - it'd be great to point people at a better way of doing things, but I'm not sure the asset_sync README is the best place ;)

[CJYate]

For what it's worth: I have three shell scripts that do the hard work:
dumpDatabase.sh

pg_dump -Fc --no-acl --no-owner -h localhost my_local_db_name > database.dump

sendDatabase.sh

PGPASSWORD=********** pg_restore --verbose --clean --no-acl --no-owner -h **********.amazon.com -U ******* -d ******* -p 5432 database.dump

syncAssets.sh

s3cmd sync public/system/refinery/images/ s3://myS3BucketName
s3cmd sync public/system/refinery/resources/ s3://myS3BucketName

s3cmd http://s3tools.org/s3cmd seems pretty good, but you may wish not to use that in official documentation....

[memoht]

I would like to +1 for keeping asset_sync supported at least with Rails 3.x apps. I have just spent the last hour struggling with assets after following the article mentioned above by @neilmiddleton - I have yet to have this all work properly now. Asset_sync made my life easy and still does. I don't want to have to precompile and check my assets into version control again. Dropping support for asset_sync feels like 2 steps backward from ease of use.

[CJYate]

Yep, me too. I really don't understand what workflow whoever comes up with
these changes expects us to use instead. Deployment should be a painless
one click / one command process. If I wanted to mess about with multiple
shell scripts I'd not be using Heroku in the first place.
On 23 Feb 2014 17:53, "guillermo haas-thompson" notifications@github.com
wrote:

I would like to +1 for keeping asset_sync supported at least with Rails
3.x apps. I have just spent the last hour struggling with assets after
following the article mentioned above by @neilmiddletonhttps://github.com/neilmiddleton- I have yet to have this all work properly now. Asset_sync made my life
easy and still does. I don't want to have to precompile and check my assets
into version control again. Dropping support for asset_sync feels like 2
steps backward from ease of use.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/242#issuecomment-35837790
.

[neilmiddleton]

Deployment should be a painless one click / one command process.

By flipping to Cloudfront the deployment process is exactly the same as the default (without the added asset_sync sync). Cloudfront allows your deploys to use all the Heroku defaults (and also benefit from the deploy speed)

[memoht]

Neil helped me with this yesterday and I am now on board. He also updated the dev center doc to cover the caveat I was hitting.

I had preselected an existing s3 bucket for my Cloudfront distribution, with a similar, but not the same name as my domain. Once I made the change, it really worked as advertised. I can now move on, but am thankful asset_sync was here for me when I needed it. :)

[CJYate]

So with Cloudfront all the assets get deployed on git push heroku master
without any extra effort? I'll have to try. At present I'm only using S3
(yes, I know its suboptimal for asset storage for a website... It's low
volume)

I think part of the problem is that Heroku (and the Gems you need to make
things work) appears to be a constantly moving target.

Chris

[PikachuEXE]

Basically it means Heroku recommends from:

User:
Browser -> CF -> S3
Deploy:
Push assets to Heroku + Sync assets to S3

to

User:
Browser -> CF -> Heroku (your app)
Deploy:
Push assets to Heroku only

[willglynn]

user-env-compile behavior is on by default effective February 24 and will therefore be removed from Labs. At the very least, it should be removed from the README.

[PikachuEXE]

Or add a note to README
For people who confused of this user-env-compile change

[neilmiddleton]

user-env-compile behavior is on by default effective February 24 and will therefore be removed from Labs. At the very least, it should be removed from the README.

Incorrect. user-env-compile will be retired and is no more. buildpack-env-arg is the replacement for this (see #251 also here), although as a Ruby developer you should see little difference. Either way, compiling assets and pushing them to S3 within the deployment mechanism is still not recommended.

[PikachuEXE]

@neilmiddleton I compile on my dev machine
But compiling on Heroku is really slow (actually we did that before but timeout occurs randomly)

[neilmiddleton]

@PikachuEXE You could try this: http://blog.alexmaccaw.com/faster-deploys. If that doesn't work raise a ticket with Heroku. You should not be having problems compiling assets and deploying within the 15 minute timeout.

[willglynn]

@neilmiddleton I understand; the specifics are now at the option of the buildpack, but the default Ruby buildpack essentially provides the old user-env-compile behavior with a blacklist. This is a detail I didn't feel a need to explain.

My point is that a) config variables now appear in the environment by default during asset compilation, and b) the user-env-compile labs feature is going away. Therefore, the section of README discussing user-env-compile needs to be changed.

[neilmiddleton]

Therefore, the section of README discussing user-env-compile needs to be changed.

Sure - although this PR is related to getting the entire section yanked as it's not a Heroku recommended path any more.

[willglynn]

We're in agreement. I mention that here because I agree that entirely removing Heroku from the README is correct solution. Putting CloudFront in front of your app is better for a lot of reasons: the Heroku release system is one, in-app cache control is another. Also, the resulting CloudFront distribution will actually handle Accept-Encoding: instead of choosing "everyone gets gzip" or "no one gets gzip" like S3.

I think that this pull request should be merged, but if someone wants to keep it, I can see room for discussion. Regardless: the README's Heroku section needs action; it's changed from "outside Heroku recommendations" to "outdated and incorrect".

(And… all that said, I am using asset_sync on Heroku – specifically for mail assets, where I find S3 + existing_remote_files = 'keep' desirable. Thank you CloudFront for letting me pattern-match multiple origins.)

[PikachuEXE]

How do you guys handle CORS with S3?
I got my workaround but that makes me cannot serve other assets from app/Heroku (since all are private)

Possible to set Cache Control to private only for some files? Middleware?