Why do we have to commit morning_glory.yml?

[kbaum]

This will be a bit of a pane to commit this using capistrano after deployment at engineyard. What's the reasoning?

REMINDER: Commit the config/morning_glory.yml file to your source control management system now.\n

Thanks!

[adamburmister]

This is important for a multi-server setup.

The morning_glory.yml contains the revision number to use on the CDN, and is updated whenever you do a deployment:

production: bucket: cdn.production.foo.com enabled: true revision: "20100317134627"

The idea was that this file would need to be committed for all servers to point to the same revision. In practice i'm not sure if it's required - if you don't delete previous revisions then older deployments will use the previous CDN asset revision.

Do you think this is a non-issue, or have any suggestions? I'm all ears.

[kbaum]

this is my first time trying this w rails and cloudfront but can we noot just forget abbot versions and overwrite the files on s3?

[adamburmister]

No. This is an imposed restriction of Amazon Cloudfront.

Once an asset has been deployed to the Cloudfront edge servers it cannot be modified - the version exists until it expires (minimum of 24 hours). To get around this we need to prefix the asset path with a revision of some sort - in MorningGlory's case we use a timestamp. That way you can deploy many times during a 24 hour period and always have your latest revision available on your web site.

I've taken this feedback into consideration and will remove that message.

In common practice I think you'll be redeploying with capistrano to all your servers after you've done a MorningGlory Cloudfront deployment anyhow, so it shouldn't be an issue.

[kbaum]

Trying to understand our workflow during deployment with capistrano. If I have to run a rake task during deployment, I usually run it on the remote server. This guarantees that if I am deploying a specific tag/branch, I am running the rake task from the correct version. I would like to follow the same approach with deploying my assets to cloudfront. I can run the morning glory rake task from one of my two servers, but then I would have to ensure that the correct version number exists within the morning_glory.yml file on the second server. Seems a bit tricky...

In this plugin, they use the git repository latest revision instead of a timestamp.

http://spattendesign.com/projects/synching-your-amazon-s3-asset-host-using-capistrano

Does that make more sense?

[adamburmister]

The git/svn revision approach seemed a bit messy to me - I tried it with the first cut of this plugin and found it lacking.

Perhaps what you'd like would be to separate out the revision-bump and deploy tasks.

That way you can bump the revision, commit, deploy, run Morning Glory on your main server and deploy into Cloudfront. With that approach you'd have satisfied your requirements, but it means an extra step for a single-server site's deployment.

[kbaum]

The problem with the two step approach is that it's difficult to consolidate that into one cap task. Right now we do:

cap production deploy -s branch=r_0.80

So we're deploying a specific tag of code to our machines. Running the version bump and committing would require us to recommit and retag.

What about the git/svn approach did you find lacking? How did that capistrano task implement it?

thx.

-karl

[adamburmister]

After more use of it on my own servers I agree. I'll see what I can do.

[adamburmister]

Updated to use git, svn revisions if found. Otherwise it'll use a datestamp (and you'll have to submit the morning_glory.yml file)