Re: Automatic deployment tool

[Cal Leeming [Simplicity Media Ltd]]

On Sun, Dec 9, 2012 at 11:40 PM, Jonathan Slenders <
jonathan.slend...@gmail.com> wrote:

> Thanks for your feedback, Cal,
>
> You're right about the documentation, some very useful parts aren't even
> documented at all. (There are comments in the code, but there are some
> little things you wouldn't know from the readme.)
>
> During the last years I also put most of the effort in experimenting and
> getting something really useful. It took a while before I got there, and it
> didn't make sense to document features which were to be refactored every
> now and then. However, now I feel its quite stable. I should start making
> better documentation, and a lot of usage examples. I also cannot deny that
> the learning curve may be a little bit steeper then Fabric in the very
> beginning, but soon you will see the advantages.
>


> If only I were as good in selling a project as I can code. :)
>

I know that feeling


>
> Anyway, I hope this can also improve automatic deployment of Django
> applications for other people.
>
> Cheers,
> Jonathan
>
>
> Le lundi 10 décembre 2012 00:15:58 UTC+1, Cal Leeming [Simplicity Media
> Ltd] a écrit :
>>
>> Hi Jonathan,
>>
>> Just from a very brief point of view.. my eyes started to glaze over
>> whilst looking at the github README, and even more so when I looked at the
>> code.
>>
>> Even if this was the best thing since sliced bread, the documentation in
>> its current state leaves me with the feeling of "why do I want to use this".
>>
>> I think what would benefit this project massively is good/easy to read
>> documentation, with a simple overview section explaining common uses, what
>> makes it better than alternatives, etc.. maybe via readthedocs..?
>>
>> Statements such as "It's as declarative as possible.." sound impressive,
>> but don't really give me much insight into what this is, and why I'd want
>> to use it.
>>
>> Hope this helps!
>>
>> Cal
>>
>> On Sun, Dec 9, 2012 at 3:30 PM, Jonathan Slenders 
>> wrote:
>>
>>> Hi Everyone,
>>>
>>> In the past there have been some discussionh about how to deploy Django
>>> web applications through SSH. How to use Fabric or other tools, and whether
>>> we should provide or maybe force users to deploy applications according to
>>> a certain conventions.
>>>
>>> Back then, maybe already more than a year ago, I said that I was working
>>> on my own deployment tool. [1] Something that could be used instead of
>>> Fabric. It's a tool which could probably help a lot of you, although it can
>>> take a while to adopt. The core consists of high quality code. I took me a
>>> while before I felt confident enough for releasing this, and it has been
>>> refactored more then any project I did before. Things still can be
>>> improved, but it's ready to share with you.
>>>
>>> Key features are:
>>>
>>>- Interactive execution of remote commands. Locally, they will
>>>appear in a pseudo terminal (created with openpty), so that even editors
>>>like Vim or Emacs works fine when you run them on the remote end. You can
>>>easy start an interactive shell on any host as well.
>>>- Reusability of all deployment code is a key point. It's as
>>>declarative as possible, but without loosing Python's power to express
>>>everything as dynamic as you'd like to. Deployment code is hierarchically
>>>structured, with inheritance where possible.
>>>- Parallel execution is easy when enabled, while keeping interaction
>>>with these remote processes possible through pseudoterminals. Every
>>>parallel task gets his own terminal, either a new xterm or gnome-terminal
>>>window, a tmux pane, or whatever you'd like to.
>>>- Logging of your deployments. New loggers are easily pluggable into
>>>the system.
>>>
>>>
>>> So, enjoy!
>>>
>>> So, what does it have to do with Django? I have a setup-definition of
>>> what we use for Django deployment [2]. However, I suppose that quite a lot
>>> of people aren't using uwsgi like us. So, I'd like to know what the most
>>> common use cases of Django deployment are. If I can cover most cases, it's
>>> very easy for end-users to pick one, override what they don't like, and
>>> enjoy the full power of this deployment system.
>>>
>>> For instance, to demonstrate the power. If we want to connect to a
>>> Django shell_plus of our Mobile Vikings production system, we type in the
>>> interactive shell:
>>>
>>> > mobile_vikings django shell_plus
>>>
>>> This will call the shell_plus function of our django setup, it will ask
>>> on which host the shell needs to be started, and immediately fire an
>>> interactive shell_plus of the remote server in your terminal.
>>>
>>> [1] 
>>> https://github.com/**jonathanslenders/python-**deployer
>>> [2] https://github.com/**citylive/citylive-operations/**
>>> blob/master/deployment/**deployer/contrib/services/**django.py

Re: Automatic deployment tool

[Jonathan Slenders]

Thanks for your feedback, Cal,

You're right about the documentation, some very useful parts aren't even 
documented at all. (There are comments in the code, but there are some 
little things you wouldn't know from the readme.)

During the last years I also put most of the effort in experimenting and 
getting something really useful. It took a while before I got there, and it 
didn't make sense to document features which were to be refactored every 
now and then. However, now I feel its quite stable. I should start making 
better documentation, and a lot of usage examples. I also cannot deny that 
the learning curve may be a little bit steeper then Fabric in the very 
beginning, but soon you will see the advantages. If only I were as good in 
selling a project as I can code. :)

Anyway, I hope this can also improve automatic deployment of Django 
applications for other people.

Cheers,
Jonathan


Le lundi 10 décembre 2012 00:15:58 UTC+1, Cal Leeming [Simplicity Media 
Ltd] a écrit :
>
> Hi Jonathan,
>
> Just from a very brief point of view.. my eyes started to glaze over 
> whilst looking at the github README, and even more so when I looked at the 
> code.
>
> Even if this was the best thing since sliced bread, the documentation in 
> its current state leaves me with the feeling of "why do I want to use this".
>
> I think what would benefit this project massively is good/easy to read 
> documentation, with a simple overview section explaining common uses, what 
> makes it better than alternatives, etc.. maybe via readthedocs..?
>
> Statements such as "It's as declarative as possible.." sound impressive, 
> but don't really give me much insight into what this is, and why I'd want 
> to use it.
>
> Hope this helps!
>
> Cal
>
> On Sun, Dec 9, 2012 at 3:30 PM, Jonathan Slenders 
> 
> > wrote:
>
>> Hi Everyone,
>>
>> In the past there have been some discussionh about how to deploy Django 
>> web applications through SSH. How to use Fabric or other tools, and whether 
>> we should provide or maybe force users to deploy applications according to 
>> a certain conventions.
>>
>> Back then, maybe already more than a year ago, I said that I was working 
>> on my own deployment tool. [1] Something that could be used instead of 
>> Fabric. It's a tool which could probably help a lot of you, although it can 
>> take a while to adopt. The core consists of high quality code. I took me a 
>> while before I felt confident enough for releasing this, and it has been 
>> refactored more then any project I did before. Things still can be 
>> improved, but it's ready to share with you.
>>
>> Key features are:
>>
>>- Interactive execution of remote commands. Locally, they will appear 
>>in a pseudo terminal (created with openpty), so that even editors like 
>> Vim 
>>or Emacs works fine when you run them on the remote end. You can easy 
>> start 
>>an interactive shell on any host as well. 
>>- Reusability of all deployment code is a key point. It's as 
>>declarative as possible, but without loosing Python's power to express 
>>everything as dynamic as you'd like to. Deployment code is hierarchically 
>>structured, with inheritance where possible. 
>>- Parallel execution is easy when enabled, while keeping interaction 
>>with these remote processes possible through pseudoterminals. Every 
>>parallel task gets his own terminal, either a new xterm or gnome-terminal 
>>window, a tmux pane, or whatever you'd like to. 
>>- Logging of your deployments. New loggers are easily pluggable into 
>>the system.
>>
>>
>> So, enjoy!
>>
>> So, what does it have to do with Django? I have a setup-definition of 
>> what we use for Django deployment [2]. However, I suppose that quite a lot 
>> of people aren't using uwsgi like us. So, I'd like to know what the most 
>> common use cases of Django deployment are. If I can cover most cases, it's 
>> very easy for end-users to pick one, override what they don't like, and 
>> enjoy the full power of this deployment system.
>>
>> For instance, to demonstrate the power. If we want to connect to a Django 
>> shell_plus of our Mobile Vikings production system, we type in the 
>> interactive shell:
>>
>> > mobile_vikings django shell_plus
>>
>> This will call the shell_plus function of our django setup, it will ask 
>> on which host the shell needs to be started, and immediately fire an 
>> interactive shell_plus of the remote server in your terminal.
>>
>> [1] https://github.com/jonathanslenders/python-deployer
>> [2] 
>> https://github.com/citylive/citylive-operations/blob/master/deployment/deployer/contrib/services/django.py
>>
>> I'll publish one of these days on pypi.
>>
>> All feedback is welcome. For bugs/feature requests on things which arn't 
>> Django related, please go to the github.
>>
>> Cheers,
>> Jonathan
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To view th

Re: Automatic deployment tool

[Cal Leeming [Simplicity Media Ltd]]

Hi Jonathan,

Just from a very brief point of view.. my eyes started to glaze over whilst
looking at the github README, and even more so when I looked at the code.

Even if this was the best thing since sliced bread, the documentation in
its current state leaves me with the feeling of "why do I want to use this".

I think what would benefit this project massively is good/easy to read
documentation, with a simple overview section explaining common uses, what
makes it better than alternatives, etc.. maybe via readthedocs..?

Statements such as "It's as declarative as possible.." sound impressive,
but don't really give me much insight into what this is, and why I'd want
to use it.

Hope this helps!

Cal

On Sun, Dec 9, 2012 at 3:30 PM, Jonathan Slenders <
jonathan.slend...@gmail.com> wrote:

> Hi Everyone,
>
> In the past there have been some discussionh about how to deploy Django
> web applications through SSH. How to use Fabric or other tools, and whether
> we should provide or maybe force users to deploy applications according to
> a certain conventions.
>
> Back then, maybe already more than a year ago, I said that I was working
> on my own deployment tool. [1] Something that could be used instead of
> Fabric. It's a tool which could probably help a lot of you, although it can
> take a while to adopt. The core consists of high quality code. I took me a
> while before I felt confident enough for releasing this, and it has been
> refactored more then any project I did before. Things still can be
> improved, but it's ready to share with you.
>
> Key features are:
>
>- Interactive execution of remote commands. Locally, they will appear
>in a pseudo terminal (created with openpty), so that even editors like Vim
>or Emacs works fine when you run them on the remote end. You can easy start
>an interactive shell on any host as well.
>- Reusability of all deployment code is a key point. It's as
>declarative as possible, but without loosing Python's power to express
>everything as dynamic as you'd like to. Deployment code is hierarchically
>structured, with inheritance where possible.
>- Parallel execution is easy when enabled, while keeping interaction
>with these remote processes possible through pseudoterminals. Every
>parallel task gets his own terminal, either a new xterm or gnome-terminal
>window, a tmux pane, or whatever you'd like to.
>- Logging of your deployments. New loggers are easily pluggable into
>the system.
>
>
> So, enjoy!
>
> So, what does it have to do with Django? I have a setup-definition of what
> we use for Django deployment [2]. However, I suppose that quite a lot of
> people aren't using uwsgi like us. So, I'd like to know what the most
> common use cases of Django deployment are. If I can cover most cases, it's
> very easy for end-users to pick one, override what they don't like, and
> enjoy the full power of this deployment system.
>
> For instance, to demonstrate the power. If we want to connect to a Django
> shell_plus of our Mobile Vikings production system, we type in the
> interactive shell:
>
> > mobile_vikings django shell_plus
>
> This will call the shell_plus function of our django setup, it will ask on
> which host the shell needs to be started, and immediately fire an
> interactive shell_plus of the remote server in your terminal.
>
> [1] https://github.com/jonathanslenders/python-deployer
> [2]
> https://github.com/citylive/citylive-operations/blob/master/deployment/deployer/contrib/services/django.py
>
> I'll publish one of these days on pypi.
>
> All feedback is welcome. For bugs/feature requests on things which arn't
> Django related, please go to the github.
>
> Cheers,
> Jonathan
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/k4RS_9Kmn9cJ.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Automatic deployment tool

[Jonathan Slenders]

Hi Everyone,

In the past there have been some discussionh about how to deploy Django web 
applications through SSH. How to use Fabric or other tools, and whether we 
should provide or maybe force users to deploy applications according to a 
certain conventions.

Back then, maybe already more than a year ago, I said that I was working on 
my own deployment tool. [1] Something that could be used instead of Fabric. 
It's a tool which could probably help a lot of you, although it can take a 
while to adopt. The core consists of high quality code. I took me a while 
before I felt confident enough for releasing this, and it has been 
refactored more then any project I did before. Things still can be 
improved, but it's ready to share with you.

Key features are:

   - Interactive execution of remote commands. Locally, they will appear in 
   a pseudo terminal (created with openpty), so that even editors like Vim or 
   Emacs works fine when you run them on the remote end. You can easy start an 
   interactive shell on any host as well.
   - Reusability of all deployment code is a key point. It's as declarative 
   as possible, but without loosing Python's power to express everything as 
   dynamic as you'd like to. Deployment code is hierarchically structured, 
   with inheritance where possible.
   - Parallel execution is easy when enabled, while keeping interaction 
   with these remote processes possible through pseudoterminals. Every 
   parallel task gets his own terminal, either a new xterm or gnome-terminal 
   window, a tmux pane, or whatever you'd like to.
   - Logging of your deployments. New loggers are easily pluggable into the 
   system.


So, enjoy!

So, what does it have to do with Django? I have a setup-definition of what 
we use for Django deployment [2]. However, I suppose that quite a lot of 
people aren't using uwsgi like us. So, I'd like to know what the most 
common use cases of Django deployment are. If I can cover most cases, it's 
very easy for end-users to pick one, override what they don't like, and 
enjoy the full power of this deployment system.

For instance, to demonstrate the power. If we want to connect to a Django 
shell_plus of our Mobile Vikings production system, we type in the 
interactive shell:

> mobile_vikings django shell_plus

This will call the shell_plus function of our django setup, it will ask on 
which host the shell needs to be started, and immediately fire an 
interactive shell_plus of the remote server in your terminal.

[1] https://github.com/jonathanslenders/python-deployer
[2] 
https://github.com/citylive/citylive-operations/blob/master/deployment/deployer/contrib/services/django.py

I'll publish one of these days on pypi.

All feedback is welcome. For bugs/feature requests on things which arn't 
Django related, please go to the github.

Cheers,
Jonathan

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