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.
