Add common_settings file

[lukavdplas]

The backend is configured using settings.py. In production environments, we replace that file with the one in our deployment module.

However, some settings are going to be the same across development and production, like the list of Django apps. This can lead to errors when we inevitably forget to update the deployment module after a release.

We can define shared settings in a common_settings.py file and import them in both the development and production settings. See https://github.com/UUDigitalHumanitieslab/I-analyzer-django/pull/51 (private repository) for an example.

[jgonggrijp]

Isn't that only a partial solution, though? Often, even though the settings are not the same in development and in production, you need to change them in both places anyway. For example, you start using a setting that was not used before, and the settings needs to be different in production but it still needs to be there in order to enable some piece of functionality. Or: you need to add an item to a list in both environments, but the lists are not identical in composition.

I think any complete solutions requires looking at the diff of the settings.py at every single release. If you do that, you don't technically need a common_settings file, although I'm not opposed to adding one, either.

I will check whether the need to diff any configuration is mentioned in our documentation on how to do a release.

[lukavdplas]

I mean, yes, in an ideal world, developers would always be thorough when preparing releases and there would be no human error 😉

In any case, a change that reduces some but not all human error is still worth it imo. Personally, I've also found that, as a solution, "I should just be more thorough from now on" is often accurate but rarely produces results.

I find a shared definition file for shared settings useful because a) you're more likely to forget about those kinds of settings, and b) those settings are supposed to be the same in every instance so defining them in one place reduces the likelihood of mistakes.

This does indeed not solve anything for settings that should be different in production, but in my experience, those settings are less likely to be forgotten during deployment because developers are aware they need to be tested in production (because the situation is actually different from development).

[jgonggrijp]

I agree with your point that it isn't easy (or even helpful) to "just be more thorough", but I think we need to work with a literal checklist when it comes to releases. Updating settings is far from the only thing that can be forgotten; I've seen people (not just inside the lab) forget to push tags, forget to bump version numbers, forget to write release notes, forget to discuss new features in documentation, forget to notify the user, forget to deploy to an acceptance server first, and so on and so forth. I have done most of those things myself, too. All those things need to be on an actual checklist and if you only need to remember to use that checklist, cutting releases actually gets a little bit easier and more reliable at the same time. Long story short, I think "review the damn configuration diff" should be on that list.

Also, it varies by the person what is or isn't likely to be forgotten. Speaking for myself, I am no more likely to remember "special" settings than I am to remember common settings. I know that I have, on at least one occasion, broken a production deployment by forgetting to update settings that were different between local development and deployment.

All that being said, I still have no objection against your proposal!

[lukavdplas]

Agreed! (Though I also know not everyone works best by strictly following a checklist.)

https://github.com/UUDigitalHumanitieslab/I-analyzer/blob/develop/documentation/Making-a-release.md may be a good starting point for that checklist.