Как я тестирую в проде и живу без venv
Меня тут недавно захейтили илитные питон прогеры из Физтеховского чатика, поэтому я решил рассказать, как веду разработку на питоне.
Напоминаю, что прогать я ненавижу, но люблю то, что достигается разработкой. Поэтому я стараюсь минимизировать для себя путь между идеей и рабочим кодом на проде. Спойлер: Для меня это все делает Heroku/Dokku.
Моя модель работает идеально, когда разработчик всего один (я). Сейчас тестирую вариант с несколькими разработчиками - пока полёт отличный.
1) Я работаю с heroku-python-buildpack, который собирает и упаковывает мое приложение в докере. На вход я подаю свой код, а на выходе он понимает, как что собирать, и возвращает готовый рабочий контейнер.
2) Для того, чтобы он все сам понял, надо подготовить два файла:
🔹 requirements.txt - список библиотек, которые нужно поставить в контейнер перед тем, как запускать код. Никакие pipenv, venv, poetry не нужны - это все приблуды корпоратов. При этом я часто не фиксирую версии библиотек: если что-то поломается, то не сбилдится - я посмотрю по логам, что не так. За полтора года такой практики, такая ситуация была только один раз.
🔹 Procfile - как и что запускать. Если нужно запустить веб-сервер и воркер (например, Django и Celery) - вам сюда.
3) Как обновлённый код попадёт в ветку Master (а я напомню, что когда работаю один, я коммичу все в мастер), CI должен автоматически начать собирать новую версию приложения. Если что-то не собралось (например, из-за Runtime или поломанной библиотеки), то контейнер не соберётся, а я по логам посмотрю, в чем проблема.
4) Весь процесс «собрать новую версию приложения в контейнер», «направить трафик на новый контейнер через nginx», «погасить старый контейнер» должен быть автоматизирован (я называю это Девопс). Раньше именно на этом этапе я тратил больше всего времени.
Сам я напрямую с докером, nginx, билдпаками никак не взаимодействую. Мое - дело писать код на питоне, а остальное должно быть автоматизировано.
Меня тут недавно захейтили илитные питон прогеры из Физтеховского чатика, поэтому я решил рассказать, как веду разработку на питоне.
Напоминаю, что прогать я ненавижу, но люблю то, что достигается разработкой. Поэтому я стараюсь минимизировать для себя путь между идеей и рабочим кодом на проде. Спойлер: Для меня это все делает Heroku/Dokku.
Моя модель работает идеально, когда разработчик всего один (я). Сейчас тестирую вариант с несколькими разработчиками - пока полёт отличный.
1) Я работаю с heroku-python-buildpack, который собирает и упаковывает мое приложение в докере. На вход я подаю свой код, а на выходе он понимает, как что собирать, и возвращает готовый рабочий контейнер.
2) Для того, чтобы он все сам понял, надо подготовить два файла:
🔹 requirements.txt - список библиотек, которые нужно поставить в контейнер перед тем, как запускать код. Никакие pipenv, venv, poetry не нужны - это все приблуды корпоратов. При этом я часто не фиксирую версии библиотек: если что-то поломается, то не сбилдится - я посмотрю по логам, что не так. За полтора года такой практики, такая ситуация была только один раз.
🔹 Procfile - как и что запускать. Если нужно запустить веб-сервер и воркер (например, Django и Celery) - вам сюда.
3) Как обновлённый код попадёт в ветку Master (а я напомню, что когда работаю один, я коммичу все в мастер), CI должен автоматически начать собирать новую версию приложения. Если что-то не собралось (например, из-за Runtime или поломанной библиотеки), то контейнер не соберётся, а я по логам посмотрю, в чем проблема.
4) Весь процесс «собрать новую версию приложения в контейнер», «направить трафик на новый контейнер через nginx», «погасить старый контейнер» должен быть автоматизирован (я называю это Девопс). Раньше именно на этом этапе я тратил больше всего времени.
Сам я напрямую с докером, nginx, билдпаками никак не взаимодействую. Мое - дело писать код на питоне, а остальное должно быть автоматизировано.