Распространенные ошибки при переносе приложения django из dev в prod?

Question

Я разрабатываю приложение django для Windows, SQLite и сервера разработки django.Я развернул его на своем хост-сервере, который работает под управлением Linux, Apache, FastCGI, MySQL.

К сожалению, у меня ошибка, возвращаемая сервером на prod, в то время как на компьютере разработчика все в порядке.Я попросил своего провайдера предоставить предпроизводственное решение, чтобы иметь возможность отладить и понять проблему.

В любом случае, каковы, по вашему мнению, наиболее вероятные ошибки, которые могут возникнуть при переносе приложения django с dev на prod?

Лучшие

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

Обновить:К вашему сведению, я внедрил сервер предварительной подготовки и уведомление по электронной почте, как предложил shanyu, и я вижу, что ошибка исходит из тег шаблона smart_if который я использую в этой новой версии.Какой-нибудь трюк с тегами шаблонов?

Обновить:Я думаю, что я исправил ошибку pb, которая была вызвана, я думаю, отправкой Filezilla по FTP.Я использовал опцию "заменить, если новее", которая, как я предполагаю, приводит к некоторым неожиданным результатам.Используя опцию "заменить все", устраните проблему.Однако для меня это была возможность узнать больше о развертывании.Спасибо за ваши ответы.

Answer 1

Проблемы, с которыми я обычно сталкиваюсь, включают:

1. Неверно настроенные производственные параметры, будь то в my production localsettings.py, файлах сайта wsgi / cgi или apache в /etc /sites-доступны
2. Различия в базе данных.Я использую Юг для миграции и столкнулся с некоторыми тонкими проблемами при выполнении моей миграции на PostgreSQL, когда она работала гладко в sqlite.
3. Статический файловый хостинг, так как я обманываю и использую сервер Django в разработке
4. Разрешения, как в файловой системе, так и внутри базы данных
5. Редкие, но возможные сетевые проблемы, из-за которых я не могу получить свои зависимости, будь то от PyPI или какого-либо стороннего сайта

Способы, которыми я смягчил эти проблемы:

• Используйте одну и ту же базу данных в производстве и разработке (в вашем случае везде MySQL).
• Я обнаружил, что полезно иметь "тестовую" среду, которая всеми возможными способами имитирует производство (это может быть на оборудовании более низкого уровня или даже на той же машине).Таким образом, если возникнут какие-либо проблемы в этом "производственном" приложении, я смогу решить их, не переводя свой производственный сервер в автономный режим.
• Запишите все для повторяемых развертываний.Я использую ткань, но zc.buildout или Асфальтоукладчик также будут работать.Эти инструменты помогают избежать опечаток при развертывании и сократить время развертывания моего приложения.
• Используйте систему управления версиями (mercurial, git, subversion) и инструмент миграции схемы (например, South), поэтому, если что-то пойдет не так при развертывании в production, у вас есть возможность отменить изменения и разрешить production работать со старым кодом со старой схемой базы данных.
• Я еще не настроил "прокси - сервер для яиц" пока нет, но я рассматриваю это, чтобы избежать проблем при загрузке зависимостей.
• Я нашел у пипа замораживание зависимостей должно быть полезным на случай, если с момента моей первоначальной загрузки в библиотеку произошло новое, несовместимое изменение
• Используйте платформу веб-тестирования, такую как Windmill или Selenium, для тестирования моего приложения в моей "тестовой" среде, чтобы я мог очень быстро получить большое тестовое покрытие моей системы.

Answer 2

Что касается вашего случая, я могу подумать о двух простых вещах, которые могут вам помочь:

<Ол>

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

Вам будет лучше, если вы настроите тестовую среду на сервере prod (скажем, test.example.com), чтобы вы могли проверить, все ли будет гладко или нет, прежде чем развертывать приложение.

Answer 3

Я полагаю, что это были подкасты, которые я слушал недавно (с Pycon 2009).:

Найдите Django в реальном мире (PyCon 2009):

http://advocacy.python.org/podcasts/pycon.rss

Части 1-3

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

Правила.