1

I'm about to start deploying, and I've had some issues problems with my live server crashing, and I can't have debug set to True.

I've got an idea of how I'd like things setup but I think I need some help.

I have a local branch, master, and a local database with Django Debug=True.
I push master to my server, where there's a live database, and a .env file with Debug set to False.

I've now setup a new local branch - debug - which has Debug=True, and using an SSH tunnel, I can connect to my live database.
All I want this for, is to run my code against the live database, with Debug set to True. So when something breaks on the server, as long as debug and master are meaningfully the same apart from the .env, I should be able to debug whatever is wrong without Debug=TRUE ever happening on the live, internet facing instance.

What I'd like is for my local debug branch to be an exact replica of master, in every way, but instead of connecting to my local database, it connects to the live one via SSH tunnel, with and Debug = True.

The problem

I have a .gitignore file called .env, and I'm running python decouple.
My .env files are referenced in that .gitignore file.
There's an .env for the live server, and one for the local master branch.

I now need a third one for debug branch - but it's not tracked by Git, so when I switch over branches, it still points at my single .env file.
If I track it, it ends up in the repository defeating the purpose of decoupling.

So far, I've hard coded the environment variables (database etc) into the settings.py file of my debug branch.

But how do I now move forward?
How can I have debug the same as master in every way other than settings.py? My .gitignore is not branch specific?
And also, how do I automatically keep debug synced with master?
Ideally, I'd have debug sync to master (apart from settings.py), and then the entire branch just never commits to the repo?

Is there a better solution to all of this?

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
phil0s0pher
  • 525
  • 10
  • 21
  • I think its best to change the .env file. I mean, in your branch(which is used in prod) should have a settings like this `debug=env.get('DEBUG', False)`, in that way you can instantly switch to DEBUG True without changing any code in branch and push it to server(it seems like a bad idea to me but thats my opinion). If you want to keep server .env file, then rename it `.env_copy` and put your env file which you need for debugging purpose – ruddra Jun 04 '19 at 06:39

1 Answers1

0

Is there a better solution to all of this?

Yes, and it involves keeping (for a given file, here env-dev.txt) different content based on branches, which means:

  • versionning only a template file env.tpl
  • version value files named after the branches: env.dev, env.master: since they are different, there is no merge issue when merging or switching branches.

For that, you would register (in a .gitattributes declaration) in your submodule repo a content filter driver.

smudge (image from "Customizing Git - Git Attributes", from "Pro Git book")

The smudge script, associate to the template file (env.tpl), would generate (automatically on git checkout) the actual env file by looking values in the right env.<branch> value file. The generated actual env file remains ignored (by the .gitignore), as you currently do.

See a complete example at "git smudge/clean filter between branches".

Your smudge script can determine the name of the checked out branch with:

branch=$(git rev-parse --symbolic --abbrev-ref HEAD)

The same idea applies to settings.py if you need branch-specific content. `

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks for a very detailed answer. So in principle it's possible, but it seems needlessly complicated. A simple solution would be to ignore a particular branch, but GIT and Simple do not go together. – phil0s0pher Jun 04 '19 at 07:05
  • @phil0s0pher It does work though: two branches, with branch-specific content. That way, you can use one or the other, and keep them in sync easily enough (since there won't be any merge conflict) – VonC Jun 04 '19 at 07:07
  • I don't doubt that it works, it just creates such friction that it starts to make me question why GIT is there at all. Git is supposed to make our lives easier, stay in the background, so we can focus on our code. The amount of time I've spent messing with GIT, trying to get a branch back, trying to revert a commit, trying to deploy, is really unjustifiable. Honestly, I've lost weeks to GIT. I find it an incredibly frustrating tool which has generally worked to stand in my way rather than to facilitate my code. – phil0s0pher Jun 04 '19 at 07:15
  • I know the inevitable, that this will now take me the rest of the day to figure out. I'll trial and error for a long time, and perhaps I'll get a result, and the whole day I won't be actually working on my project. – phil0s0pher Jun 04 '19 at 07:16
  • @phil0s0pher the idea is to reduce friction: the smudge script automates for you the generation of the right content for the file. All you have to do is to checkout the branch you want, and your files have automagically the expected content. – VonC Jun 04 '19 at 07:17
  • But this file: [filter "debug_on_off"] clean = sed -e 's/DEBUG = true/DEBUG = false/' smudge = sed -s 's/DEBUG = false/DEBUG = true/' I have no idea what that says, or what it's doing. It's automagic once I understand how to configure it and what a 'smudge script' even is, but that link you shared (thanks by the way) is a developer with more expereince than I have, and he's struggling to get it to work. The reality is, implementing something that should be incredibly simple, is going to take me hours. I find that incredibly frustrating. – phil0s0pher Jun 04 '19 at 07:22
  • @phil0s0pher the idea of the smudge script is to invoke any command you need in order to generate the right content. The example directly change the content of a file, using sed (https://www.gnu.org/software/sed/manual/sed.html), but in your case, you would be making a script to read a value file (the xxx-dev or xxx-debug files) and generate the correct xxx (ignored) file, typically with a script like https://stackoverflow.com/a/415698/6309 – VonC Jun 04 '19 at 07:29