GAE: managing dev and production versions of my app
There are a lot of things I need to do before uploading my production app to GAE. Its becoming very tedious and error-prone, and I would like to know some best-practice how to handle following requirements, and if some tools already exist for doing this:
Dev and test environment on my local machine: want to use debug versions of my javascript files, Production: want to minify the files and also concatenate them into 1. E.g.: given this code in mytemplate.html
<script src="script1.js"></script>
<script src="script2.js"></script>
<script src="script3.js"></script>
<script src="script4.js"></script>
<script src="script5.js"></script>
Wanted: some process to automatically minify the files, concatenate them into 1, and edit the code above so that it becomes:
<script src="mytemplate.js"></script>
Dev and test: use a settings.dev.py
settings.py
Some way to automatically switch to settings.py when pushing to production. i.e., I don't to manually edit all the py files and change all references to settings.dev.py to settings.py. Is a config file the recommended way to do this? I change a setting in my config.py file before pushing to production, and then the rest of the code picks up the right settings.py? Also, in python is the config f开发者_StackOverflowile a .py file, or is it something else usually - i.e., what is the norm? (in .net we usually use xml for storing configurations)
So you can detect whether your app is running in dev or production as follows:
import os
DEV = os.environ['SERVER_SOFTWARE'].startswith('Development')
Pass this bool along to your Django templates, and write conditionals when you want behavior to vary:
{% if DEV %}
<script src="script1.js"></script>
<script src="script2.js"></script>
<script src="script3.js"></script>
<script src="script4.js"></script>
<script src="script5.js"></script>
{% else %}
<script src="mytemplate.js"></script>
{% endif %}
To handle minification at the last minute, write a custom deployment script that runs any pre-deployment tasks first and then calls appcfg.py update
. When you want to deploy, run your deployment wrapper instead of calling appcfg.py directly.
You can handle your settings.py in a few different ways. Use one settings file with per-environment conditionals, import different settings files depending on the environment, or swap in the production file as part of your deployment wrapper.
精彩评论