Hello Andrew, thanks for that detailed reply. :)
So the key for development and deployment is a VCS such as SVN or Git? In short: Your developers are pushing the changes up to the branches on the stating server where a release is going to be created. Then it is going to be transfered to the production server. right? One thing I still concern about. How do you manage the production database when a application change is going to be made? For example you changed some models. To apply that changes on the development server you might just reset the database or alter it manually - it's indeed only for testing purposes - but what's with a "real" database with tons of important data? On 15 Sep., 21:49, Andrew McGregor <a...@txm.net> wrote: > You've asked a lot! I'll start with this question: > > > And final, are you developing on your local machine with the > > development server or immedeatly at the server via ssh? > > Loads of different ways, but I do this: > > * Production server - dedicated Debian host > > * Staging server - hosted Debian VM > > * Development boxes - each developer has one or more VMWare Debian instances > > > If yes, how do you deploy your project and about what points do you > > have to concern while doing that? > > As a rule of thumb you only commit code changes from dev boxes to > branches, or a tagged release if necessary. Staging should only svn > up, and production has it's own release script. > > When tested these can be merged to trunk. > > Trunk can be released to staging for UAT. > > If UAT OK then press the button for the release script to send it to > production. > > This release to live can get complicated to mitigate all issues. You > need a way to get the latest codebase live whilst minimising downtime. > You could svn co to a new dir on the same filesystem, then `mv $CUR > $OLD && mv $NEW $CUR` should be atomic, but the svn co could take time > on large systems and eat bandwidth. If you are using SVN you may be > interested in file permissions. More thank likely you have schema > changes in which case you may accept that downtime is given then you > will need some sort of maintenance mode. > > Of course, extra browny points for a wrapper around svn/git/whatever > so that on attempting a commit unit tests are run and a bunch of other > sanity checks. If OK then the commit works. > > Spend a fiver on Agile Python Development. > > http://www.amazon.co.uk/gp/offer-listing/1590599810/ref=dp_olp_used?i... > > -- > Andrew McGregor > 07940 22 33 11 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
