Heroku buildpack срабатывает только в staging pipeline, но не в prod. Особенность? Или неправильная конфигурация?
Я специально включил heroku/python
в раздел build pack для двух моих проектов Heroku Django, но build pack срабатывает только тогда, когда я развертываю проект, продвигая изменения в моей ветке main
git в staging pipeline, а не когда я продвигаю изменения в production. Почему так происходит?
Мои сборки не являются stateful (о чем Heroku упоминает в своей документации по вопросам проектирования ). Под этим я подразумеваю, что я могу обрабатывать все свои конфигурационные переменные в приборной панели Heroku с одним набором переменных для staging
и отдельным набором для production
. Нет никаких переменных, которые были бы жестко закодированы. Все мои конфигурации являются динамическими.
Проблема, которую я вижу, заключается в том, что когда я обновляю свой requirements.txt
новыми версиями модулей/библиотек Python, как мне указать Heroku запустить сборку обратно в prod, чтобы перестроить slug? Может быть, я неправильно настроил свой производственный конвейер Heroku? Или нет необходимости перестраивать slug в prod, а только в staging?
Когда я набрал название своего вопроса здесь, Stack Overflow рекомендовал следующие вопросы и ответы других пользователей, которые, казалось, не отвечали на мой вопрос:
- Ведение staging+prod окружений из одного репо, 2 удаленных с revel buildpack на heroku
- Heroku buildpack ssh config и CI pipelines
- Heroku "Multiple Buildpack" Buildpack не работает
Проблема, которую я вижу, заключается в том, что когда я обновляю
requirements.txt
новыми версиями модулей/библиотек Python, как мне проинструктировать Heroku запустить сборку обратно в prod, чтобы перестроить slug?
Зачем обновлять зависимости при переходе от staging к production? Весь смысл среды staging заключается в предварительном просмотре кода, который вы планируете запустить в production. Предварительный просмотр различного кода открывает двери для странных ошибок.
Если вы хотите обновить библиотеку, сначала сделайте это на своей машине разработки и убедитесь, что она ведет себя так, как вы ожидаете. Затем разверните на staging и снова протестируйте. Наконец, переместите staging slug в production.
Вот как должны работать трубопроводы Heroku (выделено автором):
Конвейеры позволяют определить, как развернутый код переходит из одной среды в другую. Например, вы можете развернуть код в приложении staging (которое собирает его в slug) и позже promote этот же slug в production. Этот поток продвижения гарантирует, что продакшн содержит точно такой же код, который вы тестировали в стейдже, и это также намного быстрее, чем перестраивать slug.