How to apply environment specific changes within the classic Git branching model

branchingconfiguration-managementdeployment

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)

Best Answer

Git is not suitable for managing different variants of your code.
Git is not a deployment mechanism.
Git is just a source code management system.

One thing that gets lost when using git push as a glorified FTP command is that source code is source code, and not necessarily the same thing you deploy. That even holds for interpreted systems where the source code can be executed directly.

One way to solve this is to introduce a build and deployment process that gathers the necessary files and deploys them to a certain target. Your source tree in Git might then be in a valid state for running it in a development mode, but for your production targets different config files will be used. For example, but not necessarily, a Docker image could be such a deployment format.

If a deployment target (such as Heroku) expects you to deploy via Git, it would be possible to use another repository or branch separate from your source code that contains the state to be deployed. This feels rather hackish, but actually works very well. However, this branch/repo does not contain any source code that needs to be version controlled since it's mostly a duplicate of the actual source code (from which it can be rebuilt at any time). It may therefore be occasionally desirable to prune these branches. You also lose a direct association between the deployed commit and the corresponding source code commit. Heroku may also offer other deployment types that do not abuse Git, but I'm not aware of those.

If a deployment target lets you run run pre-deployment scripts, that would be another solution. Such a script can then set up the necessary environment. For that to work, this script must be ignored by other targets or can detect under which target it is running.

In any case, adding deployment target-specific commits during your release process that are not expected to be merged back into dev is an antipattern. These will either get removed in a merge, or never become part of the history of other branches. Git is not good at maintaining a set of changes that only live on one branch if you want to merge other branches.

Decide that you don't care about these warnings

That is, if you're happy with the fact that:

git checkout <ref> will check out refs/heads/<ref> over refs/tags/<ref> (see git-checkout)
other commands will use refs/tags/<ref> over refs/heads/<ref> (see gitrevisions)

For example, in this test repository, the v1.5.2 branch points to commit B, but the v1.5.2 tag points to commit A.

% git log --oneline --decorate
8060f6f (HEAD, v1.5.2, master) commit B
0e69483 (tag: v1.5.2) commit A

git checkout prefers branch names:

% git checkout v1.5.2
warning: refname 'v1.5.2' is ambiguous.
Switched to branch 'v1.5.2'
% git log --decorate --oneline -1
8060f6f (HEAD, v1.5.2, master) commit B

but git log will use the tag name:

% git log --decorate --oneline -1 v1.5.2
warning: refname 'v1.5.2' is ambiguous.
0e69483 (tag: v1.5.2) commit A

This could be confusing.

Train people to delete their local branches when they see a new tag

This might be hard/awkward depending on the size of your organisation.

Write a wrapper around "git pull" and "git fetch"

That is, write a wrapper that checks if there are any tags that shadow branch names, and warn about (or delete) those branches. This sounds painful, and it could be undesirable if the shadowed branch is currently checked out.

Unfortunately, it sounds like the easiest way to solve this problem might be to change the way you name your branches. The link you posted uses different naming schemes for tags and branches: if you're already mostly following that method, adopting its naming scheme might be the easiest solution.

Best Answer

Related Solutions

Git Version Control – Is Creating a Tag with a Deleted Branch Name a Bad Idea?

Decide that you don't care about these warnings

Train people to delete their local branches when they see a new tag

Write a wrapper around "git pull" and "git fetch"

Related Topic