CI/CD Best Practices after Deployment

Hello Django Community!

I’m about to Deploy my first serious App but would like advice on how I can set up my Django Project so that I can easily continue developing my code locally after deployment.

My concern is that because I’m making so many changes in my settings, creating .env variables, changing databases to AWS, turning debug to false, setting up HTTPS settings and so forth. I’m also scared that deploying new features will have bugs and take down my server. (I’m going to start a business with it so I won’t be able to take them down once I get my first customer)

I’m thinking of just creating a seperate branch, but this seems like it’ll cause problems down the road when I merge. I’m reading that people often just create a seperate .settings file for production? So repeating my question, does anyone know of a way to create an efficient way to continue developing and testing locally after deployment?

There are a number of different ways to manage this. We don’t automate as much as we could, but that’s because of the approval processes for authorizing deployments.

We maintain a “staging” environment that is a complete replica of the production system. That allows us to deploy to a controlled environment, with the production settings file, to verify nothing has been messed up.

From a development perspective, yes, branches are the generally accepted best practice for making code changes. Settings can be handled by separate settings files, or by having settings retrieved from environment variables - which usually works out to be effectively the same thing.

Side note: Your SLA (service level agreement) with your customers should always identify some type of maintenance window. There are always going to be circumstances at some point in time when you’re going to want to take the system down. (At least at the “small business scale”. Obviously, a sufficiently large business has other requirements, and the budget to handle it.)

Is there any reading or tutorials you recommend? I’ve been scrounging the internet for a “best practices for django deployment” and “setting up your django project for ci/cd after deployment”. I’ve read the official docs and a few blogs but i’m still searching.

You say staging environment, so should i be preparing a docker container that mimics the heroku or railway environment i’m planning to use?

Seems like you approve the settings.py i was mentioning. Is there an efficient way to set this up? Or i’m just like copying and pasting it into my project as i switch between them?

On a Side note in case there are any other noobs reading this.
This is the best blog post i’ve found on the subject so far.

No, I don’t have anything to recommend. The problem with trying to find anything associated with deployments is that there are so many different ways to do it, and most of the decisions are external to Django. There is no one “best pattern” because you have to adapt your deployment process to the environment in which you’re working.

That’s up to you. I wasn’t presenting it as a recommendation as much as just sharing what we do. If that’s an idea that will work for you, great. If not, there are other ways.

Yes - and it (in part) depends upon how you’re going to run Django in production. For example, if you’re using gunicorn to run Django, you can specify the DJANGO_SETTINGS_MODULE environment variable to refer to your production settings file. (In case you’re not aware, it’s not actually required that your settings be in a file named settings.py.)

Changing the settings was a huge help thanks Master Ken!

Any other tips or tricks? those are the real nuggets of wisdom :slight_smile:

Question because we change the settings with

export DJANGO_SETTINGS_MODULE=production_settings

does the line in wsgi.py mean anything?

where it defaults to settings.py?

See the docs for os.environ and setdefault to understand what the line in wsgi.py does.