I understand classic branching and deployment model as saying (in some small variant of the below):
- makes the changes on dev branch
- merge dev > staging branch, deploy to staging server, test it out
- merge dev > production branch, deploy production server.
- dont make commits directly on staging or production branches. Only merge changes into those branches from dev.
My issue is with point (4): I have some files that will be different depending on whether I'm running on dev, staging or production. These may include things such as robot.txt, server launch file (maybe staging is on Heroku and launch with a Procfile while production is on EC2), etc.. things that are deployment version specific and not application version specific.
The branching model above seems to say that right after a full deployment run, production = staging = dev. However, it does not leave space for those adjustment between the different environments.
How is this solved in industry?
===== solutions I can think of =======
using environment variables on each env. Does the job for in code config switches. I already use this but I don't see how this can effect changes that are outside application code.
adding deployment changes as commits directly on staging branch and production, and merging in application changes from dev (e.g. staging maintains a different version of robot.txt then production). Seems to contradict point (4)