I have deployed my app on Heroku but am running into issues that I don't have when running the app locally. Because of this, I'm making a lot of tweaks to my code, and I'm finding that my workflow for pushing new code to Heroku takes a long amount of time (about 5 min each time), so I'm wondering if I'm doing something wrong. Before I push my code, I precompile my assets using
rake assets:precompile
This takes a few minutes to do. Then I do a commit and push my code to Heroku using:
git push heroku master
This also takes a few minutes to do. Do I need to precompile every time I push code to Heroku? Is there any way of making this process faster?
No - The Heroku Ruby buildpack will run assets:precompile for you if you haven't already.
https://devcenter.heroku.com/articles/rails-asset-pipeline
Related
I built a Rails 6 app and deployed it to Heroku. But any changes I make to the stylesheet are not reflected. All the Heroku documentation and SO questions/answers appear to no longer be relevant to the current Rails setup in this regard. I could precompile the assets before pushing to heroku but I'd prefer not to. And actually I did find a "solution" but it feels more like a hack than a real solution. If I open config/initializers/assets.rb and change the statement:
Rails.application.config.assets.version = '1.0'
to
Rails.application.config.assets.version = '1.1'
then it will update the assets. But that means if I am experimenting with the look of the site I would be changing the version all the time. I mean if that's they way it's supposed to work I'll live with it, but it doesn't seem right. Anyone know a way to get Heroku to just update it on every push?
You've to compile the assets from the heroku end(i.e. in your server on Heroku), so after pushing your code to Heroku, run:
$ heroku run rake assets:precompile
# If above doesn't work
$ heroku run RAILS_ENV=production rake assets:precompile
Also, it's a good practice to add public/assets(or whatever folder that precompiles to) folder to your .gitignore file, so incase if you precompile assets in your local environment this will not mess up with your production env when you push to Heroku. But everytime you change some CSS and push to heroku, you'll need to precomile assets on Heroku end from the above command.
I would like to ask a question about heroku and rails. As I am kind of new to rails I want to know how it works with Heroku. I have an app and would like to push it to heroku.
I know that, rails takes all js/css files and compress when you are in production mode. My problem is, when I change js or css locally and push back to same heroku app, how rails handles these changes. It would be so stupid to destroy heroku app and push again.
Everytime you make changes to your application locally you should run "bundle exec rake assets:precompile RAILS_ENV=production". This will compile your assets in the public folder and then you should commit them to git . Then upon running "git push heroku master" you will see your new assets on the deployed app once it is reloaded.
As far as destroying the app. goes, when pushing changes it is only restarted. Your database and all else are kept in tact.
I have a very small app that even uses sqlite3 in production because there are never going to be any issues with multiple writes, etc. I want to use capistrano to quickly and painlessly deploy updates to this app. But when I run cap production deploy it dumps the entire app into a release folder and symlinks it to current. I know I can include the production.sqlite3 file in the deploy.rb to keep the data but it still seems overkill to clone the entire repo every time I want to push an update.
I couldn't find anything in the capistrano documentation for updates.
Essentially all I need cap to do is
make sure my local git HEAD is the same as master
SSH into the prod server and do a git pull
Run rake db:migrate if necessary
Run rake assets:clean assets:precompile
Restart Phusion Passenger
How would I accomplish that?
Just write your own bash or ruby script that does this. I think you are missing the point of Capistrano. Cloning the whole repo allows you to do deploy rollbacks, leaving the previous version as is. It takes into account deploys that fail, and will not mess with your production site during the deploy process.
Just pushed a latest version of my Rails 4 app to Heroku which included a number of new images. All but one of the images has updated. The old images were overwritten with the new ones and hence have the same names.
I've tried wiping cache locally, wiping cache on Heroku, closing browser etc but nothing seems to work.
It works locally no problem.
Anyone have any suggestions to "force" all images to update?
Had simmiliar problem, using the following fixed the problem.
After logging onto Heroku
heroku run rake assets:clean
before pushing code to Heroku
RAILS_ENV=production bundle exec rake assets:precompile --trace
I was working on a couple of things at the time but my best understanding of how I got images to Heroku was as per above
Pierre
This is a basic, stupid question, but I configured my Rails app to deploy on Heroku, and I'm able to open the application from my Heroku account, etc. But when I want to change my code, do I need to re-deploy the whole application? I tried just committing/pushing to heroku master, but I get the error "fatal: remote end hung up unexpectedly." What should I do instead?
Also: am I supposed to run db:migrate BEFORE deploying/pushing?
There is nothing stupid about a basic question, as everyone has to start somewhere.
The basic process with deploying a Rails app to Heroku is to:
Make changes
Add and Commit your changes ($ git add files_changed.rb & $ git commit -m "make changes")
Push your changes to Heroku ($ git push heroku master)
This then pushes your code to the remote Heroku repository and redeploys your Rails application. If you have made any database migrations, you need to run:
$ heroku run rake db:migrate
This runs db:migrate on your heroku app - see how that works? :)
Running rake db:migrate locally simply migrates your local development database.