У меня есть небольшое раздражение с моим процессом push/deploy heroku, который в противном случае был радостью для обнаружения и использования.
Если я добавлю новую миграцию в свое приложение, единственный способ получить ее на сервере heroku - сделать push на удаленном сервере heroku. Это загружает его и перезапускает приложение. Но он не запускает миграцию, поэтому мне нужно сделать heroku rake db:migrate --app myapp, затем heroku restart --app myapp. Тем временем приложение не работает, потому что оно не запускало миграцию, а код ссылается на поля/таблицы и т.д. В процессе миграции.
Должен быть способ изменить процесс развертывания для автоматического запуска rake db:migrate как части процесса развертывания, но я не могу его обработать.
Это что-то, что я установил в cпанель герою? Это вариант, который я передаю герою из командной строки? Это крюк git? Может ли кто-нибудь настроить меня прямо? спасибо, max
Вот задача rake, которая завершает все в однострочный (а также поддерживает откат):
https://gist.github.com/362873
Вы все еще можете завершить развертывание поверх демонстрации своего босса, но по крайней мере вы не тратите время на ввод между git push и rake db:migrate.
Как насчет этого простого решения цепочки команд:
git push heroku master && heroku run rake db:migrate
Он автоматически выполнит миграцию, как только первая завершится успешно. Это типично 1-2 секунды задержки или меньше.
Heroku теперь имеет возможность обрабатывать это как часть своей функции "фазы выпуска".
Вы можете добавить процесс release к вашему Procfile и который будет запускаться во время каждого развертывания.
Rails >= 5 Пример
release: bundle exec rails db:migrate
Rails < 5 пример
release: bundle exec rake db:migrate
Я создал пользовательский 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
И вот мои доказательства того, что это работает:
Возможно, вы могли бы попытаться отделить свои коммиты схемы (миграции и т.д.) от коммитов (модели, проверки и т.д.).
(Обратите внимание на следующее: предполагается, что ваши изменения миграции не являются деструктивными, поскольку вы указали, что охватывает большинство ваших случаев использования.)
Ваш процесс развертывания может быть следующим:
Это, конечно, оптимальная форма, но эффективный способ избежать простоев в описанной ситуации: к моменту, когда приложение получит код для динамических полей, DB уже перенесет.
(Конечно, самым простым решением было бы просто нажать и мигрировать, пока ваш босс выйдет на обед; -D)
В противном случае, даже если модификации схемы были выполнены автоматически, вы все равно будете подвергать риску запрос, проходящий прямо перед выполнением миграций.
Просто для тех людей, которые меня любят, как я, я хочу дать здесь простое решение.
Я использую 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 по-прежнему не поддерживает никакой другой способ. И написать собственное собственное построение казалось немного излишним для столь простой вещи.
Я использую задачу rake, чтобы поместить приложение в режим обслуживания, нажимать, переносить и переносить его из режима обслуживания.
Я написал SmartMigrate buildpack, который является простым сборщиком Heroku, чтобы предупреждать о предстоящих миграциях после сборки ruby при обнаружении новых миграций. Этот buildpack предназначен для использования в Multipack, у которого есть предыдущий build файл Ruby.
При должном уважении к другим решениям здесь этот buildpack имеет 3 преимущества по сравнению с ними:
Я думаю, что подход Дэвида Сулца - единственный, который гарантирует, что вы избегаете получения запросов, пока приложение находится в неисправном состоянии.
Это немного боль, но может быть необходимо в некоторых обстоятельствах.
Как он заявил, для этого требуется, чтобы миграция 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", замените соответствующее название ветки в соответствующих местах выше.
Я использую heroku_san gem как инструмент для развертывания на некоторое время. Это приятный маленький, ориентированный инструмент для push + миграции. Он добавляет некоторые другие команды рейка, которые облегчают доступ к другим функциям (например, консоли). Помимо необходимости запоминать миграцию базы данных, моей любимой особенностью является ее конфигурационный файл Heroku, поэтому я могу назвать все свои серверы (производство, постановку, playground4, shirley), что бы я ни захотел, и держать их прямо в моей голове.