Deploying Feature in manage.py
feel
allows to sync the local folder with the remote one of the server
defining all the configuration directly in settings.py.
I've just done some months ago a simple implementation using rsync and
I reported it in active state:
http://code.activestate.com/recipes/577767-managment-command-to-deploy-a-django-project/?in=user-4174931
So, just typing:
./manage.py deploy --test
We simulate the synchronization, while:
./manage.py deploy
It'll sync all data in the remote folder.
It get the parameters of the local directory, remote directory, ip
server, etc in settings.py and automatically sync the remote server.
He helped me a lot in particular because you don't have to think about
modifying file in remote folder but every modification will be applied
always in local.
In this case I created a new command for manage.py but It would be
nice if it was in django directly.
Of course, my solution must be improved trying to get rid the
dependency with rsync and to work well in windows too. Another
improvement could be the exclude option if someone want to manage
manually some files of his own project.
How do you consider that propose??
Do you think it could be applied a new ticket feature for it??
Thanks
Aymeric Augustin
> Hi, I wanted to propose a new possible feature in Django project that
> allows to sync the local folder with the remote one of the server
> defining all the configuration directly in settings.py.
Hi Filippo,
I'm not convinced we can build a sufficiently useful and generic solution on this basis. For instance, many people prefer going through a (D)VCS rather than copying files directly between the development and production machines — it becomes necessary as soon as there's more than one developer.
Furthermore, it's a different kind of program (systems administration, not web development) and there's no advantage to tie it to manage.py.
For these reasons, it don't think it's a good idea to include this feature in Django.
Standalone tools such as Fabric are designed just to address this problem space; you can probably find one that will suit your needs.
Thanks for the suggestion anyway!
--
Aymeric Augustin.
Gabriel Hurley
Markus Gattol
Jonathan Slenders
On Oct 24, 2:18 pm, Markus Gattol <markus.gat...@gmail.com> wrote:
> I agree with others that this is better left to tools such as fabric/cuisine
> as they are build to handle these kind of tasks:http://readthedocs.org/docs/fabric/en/latest/api/contrib/project.html
I'm currently finishing a new deployment framework at my company
(Mobile Vikings), inspired by fabric and also based upon Paramiko (the
SSH) library. (It is not to reinvent Fabric, but we just needed our
deployments to be more flexibility/powerful. That is as declarative
as possible, readable, DRY and having reusable components, taking care
of cross-server dependencies/references, undo where possible, having a
deployment shell with autocomplete, easy beta/staging duplication, and
more...) If everything goes well and I'm confident, we will place the
stable source code on github and I'll post a link in django-users --
hopefully somewhere within the following two weeks.
By the way, any input of what you think a deployment tool should have,
or what you think that other tools lack is welcome. (send me in PM)
Cheers,
Jonathan
Thomas Guettler
> Hi, I wanted to propose a new possible feature in Django project that
> allows to sync the local folder with the remote one of the server
> defining all the configuration directly in settings.py.
>
> I've just done some months ago a simple implementation using rsync and
> I reported it in active state:
> http://code.activestate.com/recipes/577767-managment-command-to-deploy-a-django-project/?in=user-4174931
Hi,
I won't use rsync. Code should not be altered on the server but sometimes you (or someone else) does
it. Rsync would overwrite it. Up to now I use unison, but there are better solutions.
I would like to see a common variable in django's settings:
STAGE=...
with one of this choices: DEV, INTEGRATION, QUAL, PROD
It would be nice, if the django core could agree on a variable name and its content.
Several deploy apps could use this common variable.
In our company we have a common variable. PROD is zero:
if STAGE:
# some dev system...
--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de
Jonathan Slenders
On 25 oct, 14:28, Thomas Guettler <h...@tbz-pariv.de> wrote:
> I would like to see a common variable in django's settings:
> STAGE=...
> with one of this choices: DEV, INTEGRATION, QUAL, PROD
>
> It would be nice, if the django core could agree on a variable name and its content.
> Several deploy apps could use this common variable.
>
> In our company we have a common variable. PROD is zero:
>
> if STAGE:
> # some dev system...
CONFIG_BETA='beta' and then assign one of these three to
settings.CONFIG. Our deployment app used to replace CONFIG=CONFIG_DEV
by CONFIG=CONFIG_PROD
It would be good to agree on a naming convension for this.
However,... on newer applications, our deployment app does automatic
generation the parts from the settings (like IP addresses) which are
in production different from the development settings.
The question is, should a git/gh/... repository contain any production
specific settings? (Assuming one is using a vcs checkout.) Deployment
scripts are perfectly capable of replacing the config with production
settings right after the checkout.
Further, I think that applications should be agnostic about in what
environment they run. They should never behave different locally, in
stage or in production. You have settings which contains IP addresses,
DEBUG=True/False, etc... but I think they don't have to know whether
they run in production or not. The only reason for such a variable to
exists, may be to decide between several other settings to include.
Correct me if you think differently.
Cheers,
Jonathan
Tom Evans
> Am 23.10.2011 21:59, schrieb feel:
>> Hi, I wanted to propose a new possible feature in Django project that
>> allows to sync the local folder with the remote one of the server
>> defining all the configuration directly in settings.py.
>>
>> I've just done some months ago a simple implementation using rsync and
>> I reported it in active state:
>> http://code.activestate.com/recipes/577767-managment-command-to-deploy-a-django-project/?in=user-4174931
>
> Hi,
>
> I won't use rsync. Code should not be altered on the server but sometimes you (or someone else) does
> it. Rsync would overwrite it. Up to now I use unison, but there are better solutions.
>
>
> I would like to see a common variable in django's settings:
> STAGE=...
> with one of this choices: DEV, INTEGRATION, QUAL, PROD
>
I honestly think that trying to integrate any sort of deployment
features in django will only please the few people who use that
particular method of deploying code, and irritate the majority who do
it in a different manner. There is no 'correct' way of doing this, and
trying to find a correct way inside of django itself will only lead to
constant bike-shed discussions.
If you are interested in improving deployment, I suggest that
initially this is done outside of django. Once it is clear that your
solution is THE standard, then the discussion about bringing it inside
of django can begin (qv South).
FYI at $JOB would never countenance a deployment using
rsync/unison/scp/whatever. Each deployment is a fresh, unmodified
checkout from a specific tag/branch of an RCS, and we never update a
checkout - a completely fresh deployment is rolled for each update.
The correct settings for each backend are baked in from the RCS, and
are specific to each backend.
Cheers
Tom
Javier Guerra Giraldez
> I honestly think that trying to integrate any sort of deployment
> features in django will only please the few people who use that
> particular method of deploying code, and irritate the majority who do
> it in a different manner. There is no 'correct' way of doing this, and
> trying to find a correct way inside of django itself will only lead to
> constant bike-shed discussions.
absolutely.
I myself deploy Django apps in at least three different ways, each one
for different situations. choosing any one as _the_ official, and
replacing the others would be a downgrade for most cases.
of course, it could be done; it might even be easier for me. but it's
not what i've chosen.
--
Javier