This last week, I spent a lot of time learning about how Rails serves static files, how it interacts with a CDN like CloudFront, and how misconfigurations can really screw up your application.\u00a0 I wanted to document this here so that if I run into these situations again, I can troubleshoot them more easily.<\/p>\n
Problem #1: We did an large release, with a lot of moving pieces<\/p>\n
We (The Food Corridor) recently engaged with a consulting company to do a refresh of the look and feel of our application.\u00a0 They don’t just do UX and design, but also implementation using overseas developers and QA.\u00a0 I was excited to let said developers focus on look and feel (not my strength) but made a mistake in not setting up an entire environment for them.\u00a0 Instead, I let them use our staging environment.\u00a0 Things took longer than predicted (as they always do, and some of it was due to my availability).\u00a0 I was doing some tidying up, changing the deploy process, etc, and ended up merging a lot of changes into our codebase.\u00a0 This meant that the first release had a lot more risk that previous releases–there was some of the new look and feel as well as all my changes.<\/p>\n
That made troubleshooting any issues that came up with the release difficult, because it wasn’t clear what caused it–was it deployment changes, some of my code, some of the look and feel code?<\/p>\n
Solution #1: Set up a ‘review’ environment for any long running branches.\u00a0 I haven’t gone the full ‘review app’<\/a> path yet, but based on the docs, it doesn’t seem too hard to set up.\u00a0 For now we just have one review environment that can be shared.<\/p>\n Problem #2: Certain images appeared on staging but not on production.<\/p>\n This was one of the issues that caused some heartache during the first release.\u00a0 There were some images (svgs, to be exact) that were present on staging and not on production (from the browser, you’d get a 404).\u00a0 But staging and production had the exact same codebase, including images.\u00a0 We were doing a fresh deploy to production.\u00a0 What was the issues?<\/p>\n I rolled back a lot of the changes I’d made to make sure it wasn’t a deployment issue (turning off pipelines<\/a>, unsetting environment variables, etc).\u00a0 No love.\u00a0 We were still seeing 404s.\u00a0 Looking at the HTML, on production the image had a different name, without the hash at the end.\u00a0 From slack:<\/p>\n Interesting. on prod the envelope image is here: <limg alt=”Message” src=”https:\/\/d1soonciftqo56.cloudfront.net\/images\/tfc\/message.svg”><\/p>\n and on staging it is here: <img alt=”Message” src=”https:\/\/d1wspyydkkjqvw.cloudfront.net\/assets\/tfc\/message-c9189c257a23964ea6b97b89416b25a4.svg”> That led me to learn about the heroku asset pipeline<\/a> and in particular the way rails4 apps<\/a> are treated.\u00a0 I then dove into the compiled slug, and then saw that the Solution #2: The staging environment had some old copies of the image files. The files had been renamed, but the This last week, I spent a lot of time learning about how Rails serves static files, how it interacts with a CDN like CloudFront, and how misconfigurations can really screw […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[77,20],"tags":[],"class_list":["post-2569","post","type-post","status-publish","format-standard","hentry","category-rails","category-web-applications"],"_links":{"self":[{"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/posts\/2569","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/comments?post=2569"}],"version-history":[{"count":2,"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/posts\/2569\/revisions"}],"predecessor-version":[{"id":2571,"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/posts\/2569\/revisions\/2571"}],"wp:attachment":[{"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/media?parent=2569"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/categories?post=2569"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/tags?post=2569"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n… the svg isn’t being compiled on production for some reason<\/p><\/blockquote>\nmessage-c9189....svg<\/code> image was present in the staging slug under public\/assets<\/code> but that there was no message.svg<\/code> file in production. There was, however, a message-text-89ab....svg<\/code> file.<\/p>\nimage_tag<\/code> calls still referenced those old files. We had to update them. I also updated the build process to run a heroku repo purge-cache<\/code> every time staging was built so that we wouldn’t have any of those old files lying around, using the heroku repo plugin<\/a>\/. (It’s fine to make a mistake, but try not to make the same mistake twice.)<\/p>\n","protected":false},"excerpt":{"rendered":"