How do I merge branches between Develop - Test and Production without moving across 'test' specific code?

Question

I have a web application that has some specific differences between production and test environments. I.e. test email config, test payment config, the word Test written on the home page (useful to be sure you're in test!!)

My previous developers taught me the basics of git and I can use github desktop pro to branch and merge changes.

Now I have a test environment I don't understand how I can merge changes developers do in their own branches, into test and then onwards into Production without me losing my test environment specific configs.

Feel like I'm missing something really fundamental in knowledge but as a non-developer without any current developers to ask I'm struggling!

I needed to get some changes live recently so I used Sourcetree and the cherry pick functionality which is great but I'm probably making a bigger headache for myself down the line.

Any answers greatly appreciated. Thanks

Answer 1

You kind of answered your own question - these are config settings, and therefore belong in a configuration file (that's not promoted between dev/test/production).

In my opinion, code should never know what environment it's in. All it knows is "connect to the database using the credentials given in the config file", "display the watermark text from the config file on the home page", etc.

For your production environment you use production credentials and you set the watermark string to "".

If code knows what environment it's in, you might see something like

#IF (DEV_ENVIRONMENT)
// This is not the end of the world, but it's not great
#ELSE
// This is where alarm bells should ring.  Any code in this #ELSE block
// will, by definition, not have been tested.
//
// Maybe you have the discipline to never put code here, but what about everyone else?
#ENDIF

Answer 2

If I got you right, I see one major issue in your team's workflow:

You are using Git for deployment directly.

That is not what version control systems like Git are designed for, and even if a checkout from Git is part of a deployment, Git alone is typically not the only tool you will need for a working deployment process.

Here is a better way: your team could have something like a deployment script which copies every required artifact - but not the configuration files - from the dev environment into another environment (like your test environment, or later to production). That script could also stop the server beforehand and restart it afterwards, or do other things which are required for deploying, but which cannot be done by Git directly. And it should never ever overwrite environment specific config files.

Now, whenever you want to test a specific branch from the source tree, you use Git first to get that branch into your own local copy of the dev environment, including the developer's config files. Then you run the script for deploying the app from there to the test environment (and not changing the config there).

Note this approach assumes you already have everything which is environment dependent in a separate config file. Things like "the word Test written on the home page" should not be hardcoded in the source code, it should be configurable in some config file as well as the other things you mentioned.

If you like, you can manage your version of the test environment config files in Git as well. This could be done either in a separate repo, or in the same repo where the app is stored, but not in the real config folder. Instead, use a different folder named, for example, TestConfigFiles. The deployment script then could just take the files from there and put them in place (or you do this manually, to make sure this does not get mixed up when deploying to the production environment).