I didn't use Heroku for a while. I found Heroku change something so want to give it another try.
But after I click the "Deploy Branch" button, my app is still not working.
So I check the build log and realize Heroku seems not do the db:migrate command.
But it did do the asset:compile command. And I don't found anywhere to click to do the db:migrate thing.
So I have to do it with command line tools, right?
This is a well known limitation of Heroku. It won't run your migrations out of the box. However, you can automate it in couple of ways:
You can write a simple script that will first push new code to Heroku git repository and then run migrations. The problem is that you need to run this script locally on your machine
You can add this buildpack and then set environmental variable DEPLOY_TASKS to db:migrate. You can do this via UI, command line heroku config:set DEPLOY_TASKS='db:migrate' or you can add everything to app.json so it should work out of the box with deploy button.
You can use release phase by adding release: rake db:migrate to your Procfile.
Please keep in mind that there are many issues related to migrating your database during deployment. You can read about it in the docs for release phase.
I've never worked with Capistrano before and currently I am fighting the urge to just scrap it and go back to my old manual ways.
As I understand, Capistrano V3 does not create the initial database because they feel it is the duty of the DB administrator.
So I must be missing something but I have followed their instructions but the initial cap staging deploy fails when it gets to the rake db:migrate step because the database does not exist.
Because of the failure, the symlink for current -> releases never gets created.
Is it just accepted general practice that we SSH into our boxes and cd into the first folder under releases and manually run rake db:create...?
And then from there, am I supposed to just run cap staging deploy again so that it finishes creating the symlinks?
Seems hacky for something that is supposed to make things easier and I am not sure if I am understanding this correctly or not.
Thanks.
It does make sense to leave certain things out of a deployment. As the initial set up and the routine deployments are very separate functions and require different specialties, or in large deployments even different skillsets. That said.. I'm totally with you - on the first deploy having to manually set up the database and certain files (specifically linked files like secrets.yml) is a step that just wastes my time.
I use this plugin:
https://github.com/capistrano-plugins/capistrano-postgresql
just add the require capistrano/postgresql to your capfile as you would any plugin
then run cap staging setup before the first time you run cap staging deploy
I have successfully managed to set up a VPS production server (Ubuntu 10.04 LTS) from the excellent Railscasts episode. It's an "internal" server (not live yet), so I've been building my app locally and doing a cap deploy at regular intervals to check that things are running smoothly.
However, what I'd like to do now is delete all records on the production server (as I've just been testing stuff) - that is, to start with a completely empty database for when the site actually goes live to the public.
Obviously, I can do this locally by running something like rake db:reset, but how do I do this on the production server? Should I be adding some code to my deploy.rb file?
I'm a bit of a noob at this, but I've been unable to find anything via a Google search.
** EDIT ** Oh, and obviously this is a one-off - once things go live, I'll remove any code which deletes records!
You can ssh into the server and run any rake command from the application directory. You could create a Capistrano task just to run this one rake task, but since this task is obscenely dangerous with any real system I would not recommend it. The last thing you would want is to accidentally run it.
I've setup my app to run on Heroku with a staging and production environment as according to their documents. http://devcenter.heroku.com/articles/multiple-environments
It seems pretty straightforward to manage with the staging app, push entire deployments or new branches up to test in staging. What I wonder is how to manage the production version.
How do I keep my production up and running when deploying new code? Do I pull in the changes from staging or do I redeploy the entire app with the changes merged in?
Secondly, how do I manage and keep my database intact during all of this? I'm used to running locally where if you do a new deploy and a new rake :db:migrate, you lose all your database data. How is this done in production to not lose your records?
Thanks you and ANY other tips regarding heroku management is welcome.
Typically, you make changes locally, including migrations or whatever. Before pushing your changes to your production app, push changes to your staging app to double-check things are okay.
If you added migrations in your changes, be sure to run heroku run rake db:migrate to migrate your staging database. Running rake db:migrate should not destroy any data so long as your migration is proper - i.e. no weird tampering with data, just the standard addition/renaming/etc. of columns or introducing new tables. (Obviously if you drop a table in a migration it'll be gone.)
Then, if everything is okay with your staging app, push changes to your production, and again run heroku run rake db:migrate if you had any new migrations. If things are not okay, run heroku help to get a list of commands you can use - particularly ones with regard to releases so you can revert back to a previous release. Also heroku logs is really useful, and heroku console (actual command might be slightly different), though when you start a console, be really careful not to tamper with data too much.
With Heroku, there's no deploy command needed - right when you git push, your updated code is there. No "cap deploy" with capistrano, if you've used that before.
Hope this helps.
I have a slight annoyance with my heroku push/deploy process, which otherwise has been a joy to discover and use.
If i add a new migration to my app, the only way i can get it up onto the heroku server is to do a push to the heroku remote. This uploads it and restarts the app. But it doesn't run the migration, so i have to do heroku rake db:migrate --app myapp, then heroku restart --app myapp. In the meantime, the app is broken because it hasn't run the migrations and the code is referring to fields/tables etc in the migration.
There must be a way to change the deployment process to run the rake db:migrate automatically as part of the deploy process but i can't work it out.
Is it something i set in a heroku cpanel? Is it an option i pass to heroku from the command line? Is it a git hook? Can anyone set me straight? thanks, max
Heroku now has the ability to handle this as part of their "release phase" feature.
You can add a process called release to your Procfile and that will be run during each and every deploy.
Rails >= 5 Example
release: bundle exec rails db:migrate
Rails < 5 example
release: bundle exec rake db:migrate
What about this simple command chaining solution:
git push heroku master && heroku run rake db:migrate
It will automatically run the migrate as soon as the first one finishes successfully. It's tipically 1-2 seconds delay or less.
Here is a rake task that wraps up everything into a one-liner (and also supports rollback):
https://gist.github.com/362873
You still might wind up deploying on top of your boss's demo, but at least you don't waste time typing between the git push and the rake db:migrate.
I created a custom buildpack that gets Heroku to run rake db:migrate for you automatically on deployment. It's just a fork of Heroku's default Ruby buildpack, but with the rake db:migrate task added.
To use it with your app you'd do this:
heroku config:set BUILDPACK_URL=https://github.com/dtao/rake-db-migrate-buildpack
Also note that in order for it to work, you need to enable the user-env-compile Heroku Labs feature. Here's how you do that:
heroku labs:enable user-env-compile
And here's my evidence that this works:
Perhaps you could try separating your schema commits (migrations, etc.) commits from code commits (models, validations, etc.).
(Note the following assumes your migration changes are NOT destructive, as you've indicate covers most of your use cases.)
Your deploy process could then be:
Push schema changes to Heroku
migrate
Push application code to Heroku
This is of course far form optimal, but is an effective way to avoid downtime in the situation you've described: by the time the app receive the code for the dynamic fields, the DB will already have migrated.
(Of course, the simplest solution would be to simply push and migrate while your boss is out to lunch ;-D)
Otherwise, even if schema modifications were carried out automatically you'd still run the risk of a request passing through right before the migrations have been run.
Just for those googling folks like me I want to give a plain solution here.
I am using Rails 4 and needed to add a simple Rake task to the deployment to heroku. As I am using the 'deploy to heroku' button in github there is no chance to run "heroku run ..." immediately after deployment.
What I did: I extended the standard Rake Task 'assets:clean' that is automatically run during a deployment to heroku. The task still runs normally but I have attached my own stuff to it's end. This is done with the 'enhance' method. In the example below I add a db:migrate because this is probably what most people want:
# in lib/tasks/assets_clean_enhance.rake
Rake::Task['assets:clean'].enhance do
Rake::Task['db:migrate'].invoke
end
I admit that this is no perfect solution. But the heroku Ruby Buildpack still does not support any other way. And writing my own buildback seemed a bit of an overkill for so simple a thing.
I use a rake task to put the app in maintenance mode, push, migrate and move it off maintenance mode.
I wrote SmartMigrate buildpack which is a simple Heroku buildpack to warn of pending migrations after a ruby build whenever new migrations detected. This buildpack is intended to be part of a Multipack that has a preceding Ruby buildpack.
With due respect to other solutions here, this buildpack has 3 advantages over those:
No need for maintenance mode
No need for out-dated ruby buildpack forks that just insert the migration at the end
No need to run migrations ALL THE TIME, a warning is only displayed if new migrations are detected since the last deployment
I think David Sulc's approach is the only one which ensures that you avoid requests getting through while the app is in a broken state.
It is a bit of a pain, but may be necessary in some circumstances.
As he stated, it does require that the db migrations are non-destructive.
However, it can be difficult to push your migrations and schema changes prior to the rest of the code, as the obvious approach ('git push heroku {revnum}') relies on you having checked the migrations in before the rest of the code.
If you haven't done that, it's still possible to do this using a temporary branch:
Create a branch, based at the git revision that you most recently pushed to heroku:
git branch <branchname> <revnum-or-tag>
Check out that branch:
git checkout <branchname>
If your db migration commits only contained migrations, and no code changes, cherry-pick the commits that contain the database changes:
git cherry-pick <revnum1> <revnum2>...
If you commited your db changes in revisions which also contained code changes, you can use 'git cherry-pick -n' which won't automatically commit; use 'git reset HEAD ' to remove the files that aren't db changes from the set of things that are going to be commited. Once you've got just the db changes, commit them in your temporary branch.
git cherry-pick -n <revnum1> <revnum2>...
git reset HEAD <everything that's modified except db/>
git status
... check that everything looks ok ...
git commit
Push this temporary branch to heroku (ideally to a staging app to check that you've got it right, since avoiding downtime is the whole point of jumping through these hoops)
git push heroku <branchname>:master
Run the migrations
heroku run rake db:migrate
At this point, you might think that you could just push 'master' to heroku to get the code changes across. However, you can't, as it isn't a fast-forward merge. The way to proceed is to merge the remainder of 'master' into your temporary branch, then merge it back to master, which recombines the commit histories of the two branches:
git checkout <branchname>
git merge master
git diff <branchname> master
... shouldn't show any differences, but just check to be careful ...
git checkout master
git merge <branchname>
Now you can push master to heroku as normal, which will get the rest of your code changes across.
In the second-to-last step, I'm not 100% sure whether merging master to {branchname} is necessary. Doing it that way should ensure that a 'fast-forward' merge is done, which keeps git happy when you push to heroku, but it might be possible to get the same result by just merging {branchname} to master without that step.
Of course, if you aren't using 'master', substitute the appropriate branch name in the relevant places above.
I've been using the heroku_san gem as my deployment tool for a while. It is a nice small, focused tool for the push + migration. It adds some other rake commands that make accessing other functions (like console) easy. Beyond not having to remember database migrations, my favorite feature is its Heroku configuration file – so I can name all my servers (production, staging, playground4, shirley) whatever I want – and keep them straight in my head.