4

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

2 Answers 2

4

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
4
  • 3
    Just to add to this, it's probably worth the OP learning how to use a ".gitignore" file to help them put that a config file in the test environment which doesn't get promoted to production.
    – bdsl
    Feb 7, 2019 at 22:21
  • I think there are times when it's helpful to have some code that will run some extra sanity checks when code is in development. But this code should never alter data; it should only perform assertion types of checks or extra logging, and it should run based on configuration not hard coding (that is, it should not be code that is removed when the project moves out of dev.) In higher level languages, it may be useful to be able to manually enable it as well to allow the sanity checks in prod.
    – Ed Grimm
    Feb 8, 2019 at 6:08
  • 1
    And regarding your alarm bells comment - I've literally lost days because of bugs in such sections of code. The developer had it in test for months, claimed everything was thoroughly tested, it gets to prod, and what do you know, it doesn't work right, and the dev can't figure it out so it goes to the senior guy on the team, and since I didn't do the code review (it wouldn't have passed if I had), I get to learn all the code while we have a prod outage. Fortunately, my current team knows better.
    – Ed Grimm
    Feb 8, 2019 at 6:13
  • 1
    @bdsl: that's IMHO not sufficient, the OP needs to learn how to setup a real deployment process, which involves more than just abusing Git for this ".gitignore" has AFAIK a different purpose, not sure if that would really solve the OPs problem.
    – Doc Brown
    Feb 8, 2019 at 10:52
4

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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.