Rails 3 и Heroku: автоматически "rake db: migrate" при нажатии?

У меня есть небольшое раздражение с моим процессом push/deploy heroku, который в противном случае был радостью для обнаружения и использования.

Если я добавлю новую миграцию в свое приложение, единственный способ получить ее на сервере heroku - сделать push на удаленном сервере heroku. Это загружает его и перезапускает приложение. Но он не запускает миграцию, поэтому мне нужно сделать heroku rake db:migrate --app myapp, затем heroku restart --app myapp. Тем временем приложение не работает, потому что оно не запускало миграцию, а код ссылается на поля/таблицы и т.д. В процессе миграции.

Должен быть способ изменить процесс развертывания для автоматического запуска rake db:migrate как части процесса развертывания, но я не могу его обработать.

Это что-то, что я установил в cпанель герою? Это вариант, который я передаю герою из командной строки? Это крюк git? Может ли кто-нибудь настроить меня прямо? спасибо, max

ОТВЕТЫ

Ответ 1

Вот задача rake, которая завершает все в однострочный (а также поддерживает откат):

https://gist.github.com/362873

Вы все еще можете завершить развертывание поверх демонстрации своего босса, но по крайней мере вы не тратите время на ввод между git push и rake db:migrate.

Ответ 2

Как насчет этого простого решения цепочки команд:

git push heroku master && heroku run rake db:migrate

Он автоматически выполнит миграцию, как только первая завершится успешно. Это типично 1-2 секунды задержки или меньше.

Ответ 3

Heroku теперь имеет возможность обрабатывать это как часть своей функции "фазы выпуска".

Вы можете добавить процесс release к вашему Procfile и который будет запускаться во время каждого развертывания.

Rails >= 5 Пример

release: bundle exec rails db:migrate

Rails < 5 пример

release: bundle exec rake db:migrate

Ответ 4

Я создал пользовательский buildpack, который заставляет Heroku запускать rake db:migrate для вас автоматически при развертывании. Это просто вилка стандартного Ruby buildpack по умолчанию Heroku, но с добавленной задачей rake db:migrate.

Чтобы использовать его в своем приложении, вы сделаете следующее:

heroku config:set BUILDPACK_URL=https://github.com/dtao/rake-db-migrate-buildpack

Также обратите внимание, что для его работы вам необходимо включить функцию user-env-compile Heroku Labs. Вот как вы это делаете:

heroku labs:enable user-env-compile

И вот мои доказательства того, что это работает:

rake db:migrate on Heroku deployment

Ответ 5

Возможно, вы могли бы попытаться отделить свои коммиты схемы (миграции и т.д.) от коммитов (модели, проверки и т.д.).

(Обратите внимание на следующее: предполагается, что ваши изменения миграции не являются деструктивными, поскольку вы указали, что охватывает большинство ваших случаев использования.)

Ваш процесс развертывания может быть следующим:

  • Переместить изменения схемы в Heroku
  • мигрирует
  • Введите код приложения в Heroku

Это, конечно, оптимальная форма, но эффективный способ избежать простоев в описанной ситуации: к моменту, когда приложение получит код для динамических полей, DB уже перенесет.

(Конечно, самым простым решением было бы просто нажать и мигрировать, пока ваш босс выйдет на обед; -D)

В противном случае, даже если модификации схемы были выполнены автоматически, вы все равно будете подвергать риску запрос, проходящий прямо перед выполнением миграций.

Ответ 6

Просто для тех людей, которые меня любят, как я, я хочу дать здесь простое решение.

Я использую Rails 4 и должен добавить простую задачу Rake для развертывания в heroku. Поскольку я использую кнопку "deploy to heroku" в github, нет возможности запустить "запуск героя..." сразу после развертывания.

Что я сделал: я расширил стандартные ресурсы Rake Task: clean ', который автоматически запускается во время развертывания в heroku. Задача все еще работает нормально, но я приложил к ней все свои вещи. Это делается с помощью метода "повысить" . В приведенном ниже примере я добавляю db: migrate, потому что это, вероятно, то, что нужно большинству людей:

# in lib/tasks/assets_clean_enhance.rake
Rake::Task['assets:clean'].enhance do
  Rake::Task['db:migrate'].invoke
end

Я признаю, что это не идеальное решение. Но герою Ruby Buildpack по-прежнему не поддерживает никакой другой способ. И написать собственное собственное построение казалось немного излишним для столь простой вещи.

Ответ 7

Я использую задачу rake, чтобы поместить приложение в режим обслуживания, нажимать, переносить и переносить его из режима обслуживания.

Ответ 8

Я написал SmartMigrate buildpack, который является простым сборщиком Heroku, чтобы предупреждать о предстоящих миграциях после сборки ruby ​​при обнаружении новых миграций. Этот buildpack предназначен для использования в Multipack, у которого есть предыдущий build файл Ruby.

При должном уважении к другим решениям здесь этот buildpack имеет 3 преимущества по сравнению с ними:

  • Нет необходимости в режиме обслуживания
  • Нет необходимости в устаревших рубиновых витках, которые просто вставляют перенос в конец
  • Не нужно запускать миграцию ВСЕ ВРЕМЯ, предупреждение отображается только при обнаружении новых миграций с момента последнего развертывания

Ответ 9

Я думаю, что подход Дэвида Сулца - единственный, который гарантирует, что вы избегаете получения запросов, пока приложение находится в неисправном состоянии.

Это немного боль, но может быть необходимо в некоторых обстоятельствах.

Как он заявил, для этого требуется, чтобы миграция db была неразрушающей.

Тем не менее, может быть трудно перенаправить изменения миграции и схемы до остальной части кода, поскольку очевидный подход ('git push heroku {revnum}') полагается на то, что вы проверили миграции в остальной код.

Если вы этого еще не сделали, все еще можно сделать это с помощью временной ветки:

  • Создайте ветку, основанную на версии git, которую вы недавно нажали на герою:

    git branch <branchname> <revnum-or-tag>

  • Проверьте, что ветка:

    git checkout <branchname>

  • Если ваша миграция db фиксирует только содержащиеся в ней миграции и не изменяет код, вишня выбирает коммиты, которые содержат изменения в базе данных:

    git cherry-pick <revnum1> <revnum2>...

  • Если вы изменили свои изменения в версиях, которые также содержали изменения кода, вы можете использовать 'git cherry-pick -n', который не будет автоматически фиксироваться; используйте 'git reset HEAD', чтобы удалить файлы, которые не являются изменениями db, из набора вещей, которые будут совершены. После того, как вы получили только изменения db, скопируйте их в свою временную ветку.

    git cherry-pick -n <revnum1> <revnum2>...
git reset HEAD <everything that modified except db/>
git status
... check that everything looks ok ...
git commit

  • Нажмите эту временную ветвь на герою (в идеале, в промежуточное приложение, чтобы проверить, что у вас все в порядке, так как избежать простоев - это целая точка прыжка через эти обручи)

    git push heroku <branchname>:master

  • Запуск миграции

    heroku run rake db:migrate

  • В этот момент вы можете подумать, что вы можете просто нажать "master" на герою, чтобы получить изменения кода. Однако вы не можете, так как это не ускоренное слияние. Путь к продолжению состоит в том, чтобы объединить оставшуюся часть "мастера" в вашу временную ветвь, а затем объединить ее с мастером, которая рекомбинирует истории фиксации двух ветвей:

    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>

  • Теперь вы можете нажимать master на heroku как обычно, чтобы получить остальные изменения кода.

На втором-последнем этапе я не уверен на 100%, нужно ли объединить master с {branchname}. Выполнение этого способа должно гарантировать, что выполняется слияние "fast-forward", которое сохраняет git счастливым, когда вы нажимаете на герою, но возможно получить тот же результат, просто слияние {branchname}, чтобы овладеть без этого шага.

Конечно, если вы не используете "master", замените соответствующее название ветки в соответствующих местах выше.

Ответ 10

Я использую heroku_san gem как инструмент для развертывания на некоторое время. Это приятный маленький, ориентированный инструмент для push + миграции. Он добавляет некоторые другие команды рейка, которые облегчают доступ к другим функциям (например, консоли). Помимо необходимости запоминать миграцию базы данных, моей любимой особенностью является ее конфигурационный файл Heroku, поэтому я могу назвать все свои серверы (производство, постановку, playground4, shirley), что бы я ни захотел, и держать их прямо в моей голове.