Django deployment questions

[Mike]

I just started to use Fabric to automate my deployments to my staging server. (and when I'm ready, to the production server as well).  I have just a few questions for more experienced folks:

Do you clone your whole git repository onto your server, or upload a new archive each time you release?  Seems like it would be easier to switch versions of the running code, by switching tags, but it would use up a lot more disk space. I'd also have to have an ssh key to the central git repository on the web server.  Sounds like that could be a security issue. At the moment I'm programming Fabric to upload an archive, untar it, and symlink it to a fixed directory where the web server expects it to be.

Do you log out all users or just reset the sessions (manage.py reset sessions)?

thanks!

[Phang Mulianto]

Hi,

i just use git only, create Gits bare repo in the server , upload via git push [ssh of course] , then use the hook/post-update script to pull the git in the production code.

so only change/ updated part in the code got uploaded. save Bandwidth, and also reduce error, also faster deploy.

for the user part, i still have no idea, coz i use gunicorn , i think it automaticly reload the new py file.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/jIsZUTiptKQJ.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

[Mike]

On Sunday, September 2, 2012 10:29:52 AM UTC+2, Mulianto wrote:

Hi,

i just use git only, create Gits bare repo in the server , upload via git push [ssh of course] , then use the hook/post-update script to pull the git in the production code.

thats a good idea, I forgot about the hook scripts, and of course I could git push without leaving a ssh key on the server. Well, now I have it working by uploading tarballs but its something I can revisit in the future

Thanks

Mike 

[Matt Stevens]

Hi Mike,

I think this is a matter of preference. I've always cloned the entire repository - new features can go live by simply checking out a new branch, if something goes wrong I can just checkout the (stable) master branch again. I can also see if any boxes are out of sync with the current codebase with git diff. Having this all wrapped up in fabric tasks makes everything tidy and painless to deal with.

I've never had any security issues with this, if I had a compromise I would just drop the SSH key of the compromised box from my central Git server (Github in my case) and restore the repo from my daily backups. If this is more of an issue for you though then something like Gitosis would help. 

Cheers,

Matt Stevens | http://www.dirtymonkey.co.uk

[Matt Stevens]

One more thing, my repositories are usually quite small. My virtualenv and static file directories are in my .gitignore, so they're never included. So cloning an entire repo isn't a big deal and disk space itself is very rarely a problem (and when it is, it's not down to the size of the repo).

[Stephen Anto]

Hi Guys,

For Django related questions and answers Pls visit http://www.f2finterview.com/web/Django/