Oh also, if you want to run off dev.* / staging.* urls, but your code (for
whatever reason) won't support those new urls, you can use middleware to
trick the code into thinking the dev.*/staging.* hostnames are actually the
prod hostnames, whilst still applying the correct environmental settings:


            # Do some clever stripping of dev.*
            if host[:4] == "dev.":
                host = host[4:]
                #request.META["HTTP_HOST"] = host
                #request.META['SERVER_NAME'] = host
                if request.META.has_key('HTTP_REFERER'):
                    request.META['HTTP_REFERER'] =
request.META.get('HTTP_REFERER').replace("//dev.", "//")

                if request.META.has_key('SCRIPT_URI'):
                    request.META['SCRIPT_URI'] =
request.META.get('SCRIPT_URI').replace("//dev.", "//")

etc..

On Fri, Jun 3, 2011 at 9:54 PM, Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk> wrote:

> Oh, sorry I thought you were asking how to stop people accessing your dev
> environment.
>
> There are multiple ways to handle dev/staging/prod separation, and they all
> depend on how mission critical your prod is.
>
> Personally, I have different sub domains for each one, place prod under git
> only release control, and have dev/staging locked down.
>
> In the settings.py, I then separate the environments out by using
> environmental variables. For example:
>
> DJANGO_ENVIRONMENT=prod ./manage.py shell
> DJANGO_ENVIRONMENT=dev ./manage.py shell
>
> You can also do auto env detection, based on the current path, by using the
> following:
>
>
> CURRENT_DIR = os.path.dirname(__file__)
>
> if not os.environ.has_key('DJANGO_ENVIRONMENT'):
>     if CURRENT_DIR.count("/ddcms/dev"):
>         os.environ['DJANGO_ENVIRONMENT'] = 'dev'
>
>     elif CURRENT_DIR.count("/ddcms/prod"):
>         os.environ['DJANGO_ENVIRONMENT'] = 'prod'
>
>     else:
>         assert os.environ.has_key('DJANGO_ENVIRONMENT'), "Auto environment
> resolve failed, you must specify which DJANGO_ENVIRONMENT to use (dev/prod)"
>
> To resolve relative include problems, you can also use this to grab the
> current root dir of your project:
>
> # Hard code the root folder for production, due to symlinking resolve
> problems.
> if os.environ.get('DJANGO_ENVIRONMENT') == 'prod':
>     PROJECT_PATH = "/ddcms/prod/webapp"
> else:
>     PROJECT_PATH =
> os.path.abspath(os.path.dirname(__file__)+"/").replace('\\',"/")
>
> If you need your dev/prod to use the same database source, you can also use
> middleware and db routers to control how much damage dev can cause etc.
>
> Cal
>
> On Fri, Jun 3, 2011 at 9:50 PM, AJ <brandmys...@gmail.com> wrote:
>
>> Well even if I do my Python stuff in virtualenv for development on a
>> linode box, I'd like to know how to separate development/test environment to
>> live/production.
>>
>> Is the only solution "*...**IP whitelisting to block only those who you
>> want to have access...*"?
>>
>> Also, can I run multiple instances of same Django website on
>> dev.website.com, test.website.com and www.website.com?
>>
>>
>>
>>
>> On Fri, Jun 3, 2011 at 4:28 PM, Shawn Milochik <sh...@milochik.com>wrote:
>>
>>> On 06/03/2011 04:16 PM, Amanjeev Sethi wrote:
>>>
>>>> Linode looks nice plus it will teach me some administration side too.
>>>>
>>>> If I try using linode, what is the best setup (Linux Distro, web server
>>>> support, modules like mod_wsgi? etc ) for Django websites on linode?
>>>>
>>>>
>>>>
>>> Use whatever distro you like and do all your Python stuff in virtualenv.
>>>
>>> For deployment I use and recommend nginx + gunicorn.
>>>
>>> Use supervisord to run gunicorn.
>>>
>>> Shawn
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Django users" group.
>>> To post to this group, send email to django-users@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.
>>>
>>>
>>
>>
>> --
>> AJ
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To post to this group, send email to django-users@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.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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.

Reply via email to