On Mon, Oct 25, 2010 at 7:04 PM, Jumpfroggy <rocketmonk...@gmail.com> wrote: > This is such a great thread! I'd love to see a wiki page detailing > some good setup ideas. It's such a leap forward from the nuts & bolts > of "How do I install django" and "How do I run a complex query" to > this... "How do I use django more effectively, end to end?" > > I agree - most of these tips will be generic to project dev & > deployment, but it seems there are a few django specific ones. > > My thoughts... > > - Use VCS. First step. I use SVN, but others are probably better. > Even if you're a solo dev, even for small projects, it's worth it. >
Others are 'cooler'. I'm not sufficiently versed in git or mercurial to comment on whether they can handle the structures I'll describe below.. > > - +1 on using "settings.py" and "local_settings.py". The problem with > keeping local settings files in the VCS is when you have multiple > servers with different settings. You could store each file as > local_settings_test_server.py and so on. Then you could have > something like "settings_server_name.py" that's not in VCS, and it > only has: > > SERVER_NAME = 'prod' > > And in your settings.py: > > import * from settings_server_name > > if SERVER_NAME == 'prod': > import * from settings_prod_server > elif SERVER_NAME == 'test': > ... > etc > Bit clunky isn't it? Every time you add/remove an instance of the project, you have to update settings.py. This is how I structure my projects in the svn repository (hope you can all see unicode line segments!): sample_project ├── configurations │ ├── development-requirements.pip │ ├── production-requirements.pip │ ├── settings_local-app01.py │ ├── settings_local-app02.py │ ├── settings_local-dev-app01.py │ └── settings_local-dev-app02.py ├── deployments │ ├── app01 │ │ ├── logs │ │ └── scripts │ ├── app02 │ │ ├── logs │ │ └── scripts │ ├── dev-app01 │ │ ├── logs │ │ └── scripts │ └── dev-app02 │ ├── logs │ └── scripts ├── scripts │ ├── bootstrap │ └── project └── src ├── releases │ ├── 1.0 │ │ └── htdocs │ ├── 1.1 │ │ └── htdocs │ └── 1.2 │ └── htdocs └── trunk └── htdocs Each deployed instance of the project gets a folder in sample_project/deployments. The deployment then uses svn externals to include the parts of the project it requires: src/<some branch> is externalled into dep/sample_project configurations/settings_local-<instance>.py is file externalled into dep/sample_project/settings_local.py configurations/<one of the pip files> is file externalled into dep/scripts/requirements.pip scripts/{bootstrap,project} are file externalled into dep/scripts/ You end up with a structure like this: instance ├── environ │ ├── bin │ ├── include │ └── lib ├── htdocs ├── logs ├── run ├── sample_project │ ├── __init__.py │ ├── settings.py │ ├── settings_local.py │ └── urls.py └── scripts ├── bootstrap ├── project └── requirements.pip The 'bootstrap' script is a simple script that sets up the virtualenv and installs/upgrades all packages to the specification specified in requirements.pip, using pip. The 'project' script is a rc script for plugging into the OS's rc infrastructure. Every single file is tracked by VCS, every change in the project structure is versioned and controlled for change management processes. Changes to a production environment can be reliably tested, checked and repeated. New instances simply require a new settings_local-<instance>.py created in the configuration repo, new packages can be tried in development and it is simple and repeatable to deploy to production. There are a number of other tools that I use to do change management (Fabric and south mainly), but it would take too long to go into those as well! Cheers Tom -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.