5👍
I’d probably use Mercurial Queues for something like this. Keep the main repository as the development version, and have a for-production
patch that makes any necessary changes for production.
2👍
Here are two possible solutions one using mercurial and one not using mercurial:
- Use the hostname to switch between prod and devel. We have a single check at the top of our settings file that looks at the SERVER_NAME environment variable. If it’s www.production.com it’s the prod DB and otherwise it picks a specified or default dev/test/stage DB.
- Using Mercurial, just have a clone that’s dev and a clone that’s prod, make all changes in dev, and at deploy time pull from dev to prod. After pulling you’ll have 2 heads in prod diverging from a single common ancestor (the last deploy). One head will have a single changeset containing only the differences between dev and prod deployments, and the other will have all the new work. Merge them in the prod clone, selecting the prod changes on conflict of course, and you’ve got a deployable setup, and are ready to do more work on ‘dev’. No need to branch, transplant, or use queues. So long as you never pull that changeset with the prod settings into ‘dev’ it will always need a merge after pulling from dev, and if it’s just a few lines there’s not much to do.
- Django settings.cpython-36.pyc not ignored by gitignore
- How do I execute an arbitrary script in the context of my Django project?
- How to logout in django?
- How to solve the ImportError: cannot import name simplejson in Django
- Django ORM group by, and find latest item of each group (window functions)
2👍
I’ve solved this with local settings.
-
Append to settings.py:
try: from local_settings import * except ImportError: pass
-
touch local_settings.py
- Add
^local_settings.py$
to your.hgignore
Each deploy I do has it’s own local settings (typically different DB stuff and different origin email addresses).
PS: Only read the “minified versions of javascript portion” later. For this, I would suggest a post-update hook and a config setting (like JS_EXTENSION).
Example (from the top of my head! not tested, adapt as necessary):
- Put JS_EXTENSION = ‘.raw.js’ in your
settings.py
file; - Put JS_EXTENSION = ‘.mini.js’ in your
local_settings.py
file on the production server; - Change JS inclusion from:
<script type="text/javascript" src="blabla.js"></script>
To:
<script type="text/javascript" src="blabla{{JS_EXTENSION}}"></script>
- Make a post-update hook that looks for
*.raw.js
and generates.mini.js
(minified versions of raw); - Add
.mini.js$
to your.hgignore
- Count lines of code in a Django Project
- Adding Autoincrement field to existing model with Django South?
- How to make action logging in Django with Django Rest Framework
- Django manage.py runserver verbosity
1👍
Perhaps try something like this: (I was just thinking about this issue, in my case it’s a sqlite database)
- Add
settings.py
to .hgignore, to keep it out of the repository. - Take your
settings.py
files from the two separate branches and move them into two separate files,settings-prod.py
andsettings-dev.py
- Create a deploy script which copies the appropriate settings-X file to settings.py, so you can deploy either way.
If you have a couple of additional files, do the same thing for them. If you have a lot of files but they’re all in the same directory by themselves, you could just create a pair of directories: production
and development
, and then either copy or symlink the appropriate one into a deploy
directory.
If you did something like this, you could dispense with the need for branching your repository.
- How to handle Python multiprocessing database concurrency, specifically with django?
- Filter queryset by reverse exists check in Django
- Django: lock particular rows in table
- Django annotate whether exists or not
1👍
I actually do this using named branches and straight merging instead of transplanting (which is more reliable, IMO). This usually works, although sometimes (when you’ve edited the different files on the other branch), you’ll need to pay attention not to remove the differences again when you’re merging.
So it works great if you’re not changing the different files much.
- Django: taking input and showing output in the same page
- DRF many-to-one reverse lookup
- Implementing HATEOAS in Django REST framework