3 ms·

These are some excellent points, the only things we do differently are: - We keep a local settings file for each environment, and those /are/ versioned. We hav

These are some excellent points, the only things we do differently are: - We keep a local settings file for each environment, and those /are/ versioned. We have a /settings_local directory which contains each of the variants (localdev/dev/staging/df/live). The appropriate one is sym linked to /settings_local.py, which in turn is imported into settings.py. - We bypass Apache entirely and just plug Nginx FCGI into Django directly. - We have a separate pip requirements file for each environment (also kept in source control) - We use a Puppet to configure our systems. Perosonally though, I have found Puppet to have an exceptionally steep learning curve, so you may want to shop around. I hope that helps!

stakent 16y ago
I use fabric for deployment, testing, log maintenance, database backups. For almost everything on remote machines. Learning curve is rather not steep.
- b14ck 16y ago
  +1 for fabric. If you haven't used fabric, give it a try. It's an extremely simple API for performing remote management, deployment, etc. I've tried numerous tools but nothing compares to fabric. It is just so easy and it always works. I can't imagine not seeing a fabfile.py in my project's deploy/ dir anymore, it just wouldn't be right.
oscarduignan 16y ago
> - We keep a local settings file for each environment, and those /are/ versioned. We have a /settings_local directory which contains each of the variants (localdev/dev/staging/df/live). The appropriate one is sym linked to /settings_local.py, which in turn is imported into settings.py. I didn't read your comment (thoroughly) before posting my comment above, so I was parroting your point about organising project settings, however there are a few differences between our approaches. And I'd be interested to hear what you think about them. I don't work that actively with django at the moment, and never really had the opportunity to use my above system in a commercial project so maybe (probably) there are some gotchas I haven't thought about!

stakent 16y ago

I use fabric for deployment, testing, log maintenance, database backups. For almost everything on remote machines. Learning curve is rather not steep.

b14ck 16y ago
+1 for fabric. If you haven't used fabric, give it a try. It's an extremely simple API for performing remote management, deployment, etc. I've tried numerous tools but nothing compares to fabric. It is just so easy and it always works. I can't imagine not seeing a fabfile.py in my project's deploy/ dir anymore, it just wouldn't be right.

oscarduignan 16y ago

> - We keep a local settings file for each environment, and those /are/ versioned. We have a /settings_local directory which contains each of the variants (localdev/dev/staging/df/live). The appropriate one is sym linked to /settings_local.py, which in turn is imported into settings.py. I didn't read your comment (thoroughly) before posting my comment above, so I was parroting your point about organising project settings, however there are a few differences between our approaches. And I'd be interested to hear what you think about them. I don't work that actively with django at the moment, and never really had the opportunity to use my above system in a commercial project so maybe (probably) there are some gotchas I haven't thought about!