На Heroku существует ли опасность миграции Django syncdb/South после того, как экземпляр уже перезапустился с измененным кодом модели?

Ответ 1

Самый безопасный способ обработки миграции такого рода, Heroku или нет, - это строго придерживаться подхода совместимости с вашей схемой и кодом:

• Каждое изменение аддитивной или преобразующей схемы должно быть обратно совместимым;
• Каждое изменение деструктивной схемы должно выполняться после удаления кода, который зависит от него;
• Каждое изменение кода должно быть:
  • устойчив к возможности того, что связанные изменения схемы еще не были выполнены (например, удаление модели или поля на модели) или
  • сделано только после того, как было выполнено соответствующее изменение схемы (добавление модели или поля на модель)

Если вам необходимо сделать значительное преобразование модели, для этого подхода могут потребоваться следующие шаги:

• Создайте новую таблицу базы данных, чтобы сохранить новую структуру модели и развернуть эту миграцию.
• Создайте новую модель с новой структурой и код, чтобы скопировать изменения старой модели в новую модель при изменении старой модели и развернуть этот код
• Выполните миграцию или действие кода, чтобы скопировать все старые данные модели в новую модель.
• Обновите свою кодовую базу, чтобы использовать новую модель, а не старую модель, удалив старую модель и разверните ее.
• Выполнить миграцию для удаления старой структуры модели из базы данных

С некоторыми размышлениями и планированием он может быть использован и для более радикальных изменений:

• Развернуть код, полностью удаляющий зависимость от раздела базы данных, предположительно заменяющего эти разделы сайта страницами обслуживания
• Разверните миграцию, которая приведет к радикальным изменениям, которые по какой-либо причине не будут работать с описанным выше рабочим процессом с двойной моделью.
• Развернуть код, который возвращает поврежденные разделы с поддержкой новой модели.

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

Ответ 2

Похоже, что быстрое переключение баз данных - это путь, но для этого требуется специальная база данных.

http://devcenter.heroku.com/articles/fast-database-changeovers

В качестве альтернативы, здесь приведен учебник для копирования данных из одной базы данных (например, производства) в другую базу данных (например, постановка), выполнение миграции схемы/данных (например, с использованием django/south), затем переход приложения на использование обновленный экземпляр базы данных.

http://devcenter.heroku.com/articles/migrating-data-between-plans

Кажется разумным, но потенциально медленным, если имеется большой объем данных.

Ответ 3

Рекомендуемый метод:

• Добавить изменения базы данных для новых функций в существующий код
• Сделать существующий код совместимым с новой схемой
• Deploy
• Добавьте новые функции в свою кодовую базу
• Deploy

Это означает, что изменения в базе данных уже существуют, когда код начинает их требовать.

Однако....

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

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

Честно говоря, нет четкого пути для того, как справиться с этим, так как по определению ваш код должен быть на месте для изменения базы данных. Лучшим способом, который я нашел для решения этой проблемы, является просмотр каждого изменения по отдельности и выработка наиболее гладкого пути для каждого в каждом конкретном случае.

Репетирование развертываний в промежуточной среде уменьшит риск неудачи развертывания и даст вам представление о влиянии.

Ответ 4

Недавно Heroku выпустила " buildpacks", которые являются сценариями, которые они используют для настройки среды для вашего приложения, от управления зависимостями до перезапуска экземпляры. По сути, это более всеобъемлющий Procfile, который вы можете настроить.

Вы можете развернуть Python buildpack и изменить script для запуска в нужной последовательности. Добавьте команду, которую вы выполняете, до syncdb до конца bin/steps/django. Зафиксируйте и поставьте это репо на Github.

К сожалению, на данный момент невозможно изменить buildpack существующего приложения Heroku, поэтому вам придется удалить его и заново создать тот, который указывает на ваш репозиторий buildpack:

heroku create --stack cedar --buildpack [email protected]:...

Это лучшее решение, потому что оно

• Не стоит ничего вообще
• Не требует, чтобы вы адаптировали свой код к Heroku
• Только синхронизация db один раз для развертывания

Надеюсь, что это поможет.