#django #git #heroku
#джанго #git #heroku #django
Вопрос:
Я использую heroku для разработки приложения Django, а они используют git для отправки кода. Моя проблема в том, что им нужна эта файловая структура:
heroku_project/
requirements.txt (this a pip requirements file)
procfile (this file tell heroku how to run your app)
django_project (the project itself)
lib
bin
build
lib (these 4 folders belong to my python virtual env)
Итак, мне нужно, чтобы мой git был инициализирован в этой папке, чтобы это означало, что есть эти дополнительные файлы:
heroku_Project/
.gitignore
.git
Согласно их инструкциям внутри .gitignore
должны быть такие строки:
bin
build
include
lib
.Python
*.pyc
Проблема в том, что я хочу отслеживать эти виртуальные папки env, потому что иногда я устанавливаю python только для тестирования и удаляю их позже, или я вношу в них экспериментальные изменения, и я хотел бы отменить эти изменения с помощью git, мой вопрос в том, как я могу отслеживать эти папки, поэтому мне нужно удалить их из .gitignore
. Проблема в том, что когда я делаю
git push heroku master
Поскольку это приведет к удалению этих папок, а мы этого не хотим, так как же я могу выборочно отправлять файлы и каталоги? Или какой вид рабочего процесса вы бы использовали для решения этой проблемы?
Спасибо
Ответ №1:
Во-первых, если вы активно развиваетесь в Heroku, то, возможно, вы в тупике. Но если вы занимаетесь разработкой на своем локальном компьютере — филиалы могут вам помочь.
Моим советом вам было бы создать отдельную ветку для развертывания кода в heroku. В этом сценарии вы могли бы использовать главную ветвь для активной разработки и сохранить там эти папки виртуальной среды — и иметь отдельную ветвь (скажем, «производство») для развертывания кода в heroku.
Всякий раз, когда вы будете готовы выпустить новую версию своего кода, вам следует переключиться на производственную ветку, объединить изменения с master, удалить эти папки виртуальной среды, а затем отправить в Heroku. На практике эта последовательность команд будет выглядеть примерно так.
$ git checkout production
$ git merge master
$ rm -Rf bin build include lib .Python *.pyc
$ git commit -a -m "Cleanup for production."
$ git push heroku production
Кажется, что это будет лучшее рабочее решение. Некоторые векторы, которые вы, возможно, захотите изучить самостоятельно:
- Способы автоматизации процесса удаления файлов с помощью сценариев оболочки и git-хуков.
- Чтобы убедиться, что Heroku может использовать ветку, отличную от «master», для запуска кода (я бы подумал, что это должно быть возможно).
- Чтобы посмотреть, возможно ли использовать разные
.gitignore
файлы в разных ветвях, и если да, то удалит ли это процесс очистки от удаления этих файлов вручную.
Надеюсь, это поможет!
Комментарии:
1. Спасибо за ответ, да, я занимаюсь локальной разработкой. Я боялся, что это потребует изменений в рабочем процессе, но я думаю, что смогу автоматизировать это с помощью скриптов fabric или shell.
Ответ №2:
Почему бы вам не попробовать virtualenvwrapper? Это отделяет virtualenv от вашей среды разработки. Типичный сценарий заключается в том, что вы работаете с одним виртуальным файлом, скажем, «main_env».
mkvirtualenv main_env
И когда вам понадобится еще один для тестирования, вы можете сделать
mkvirtualenv test_env
и вы можете переключаться между ними одной командой: workon [name]
. Вы действительно не должны хранить эти файлы в git. Они просто не связаны с проектом. И благодаря virtualenwrapper вам не нужен git для переключения между этими виртуальными средами.
Если вы настаиваете на их сохранении, вы можете просто НЕ размещать их в git. Если вы не добавите файл / папку с git add
, он не будет отправлен на сервер.
Комментарии:
1. Я думал об этом, но у меня был такой кошмар, когда я манипулировал путем python для virtualenv, для vim и для ipython, что я хочу избежать возни с ним, используя другой virtualenv.
2. Ну, тогда явно что-то было не так 🙂 Настройка virtualenvwrapper очень, очень проста и подробно объяснена (просто ознакомьтесь с инструкциями по установке и убедитесь сами). Если у вас установлен ipython, то при запуске
manage.py shell
запустится настроенная django оболочка ipython. Это просто работает.