I have specifically included heroku/python in the build pack section for my two Heroku Django projects but the build pack is triggered only when I deploy by pushing my changes in my main git branch to the staging pipeline, not when I promote the changes to production. Why is that?

My builds are not stateful (as Heroku addresses in their doc on design considerations). By that I mean that I can handle all my configuration variables in the Heroku dashboard with one set of variables for staging and a separate set for production. There are no variables that are hard coded. All my configurations are dynamic.

The problem I see is that when I update my requirements.txt with newer versions of Python modules/libraries, how do I instruct Heroku to trigger the build back in prod to rebuild the slug? Have I misconfigured my Heroku production pipeline? Or is it somehow unnecessary to rebuild slugs in prod but only in staging?

When I typed the title for my question here, Stack Overflow recommended the following questions and answers from other users which didn't seem to answer my question:

• Maintaining staging prod environments from single repo, 2 remotes with revel buildpack on heroku
• Heroku buildpack ssh config and CI pipelines
• Heroku "Multiple Buildpack" Buildpack not working

CodePudding user response：

The problem I see is that when I update my requirements.txt with newer versions of Python modules/libraries, how do I instruct Heroku to trigger the build back in prod to rebuild the slug?

Why would you update your dependencies when promoting from staging to production? The whole point of a staging environment is to preview the code you're planning to run in production. Previewing different code opens up the door to weird bugs.

If you want to upgrade a library, first do it on your development machine and make sure it behaves as you expect it to. Then deploy to staging and test again. Finally, promote the staging slug to production.

This is how Heroku Pipelines are meant to work (emphasis added):

Pipelines let you define how your deployed code flows from one environment to the next. For example, you can deploy code to your staging app (which builds it into a slug) and later promote that same slug to production. This promotion flow ensures that production contains the exact same code that you tested in staging, and it’s also much faster than rebuilding the slug.