[Grok-dev] Re: grokdeploy tool idea

Martijn Faassen faassen at startifact.com
Tue Jun 3 11:21:54 EDT 2008

Peter Bengtsson wrote:
> I like the idea of that ultimate goal but it sounds excessively
> complicated considering that everybodys deployment strategies seem to
> be different. Basically, all it should really require is the ability
> to do an svn commit locally following a svn update + zopectl restart
> on the server.

I think it wouldn't hurt to standardize on a few common deployment 
strategies. Requiring that you have a certain thing on a server 
available isn't a bad thing, I think. WSGI can help here, as it makes 
web servers more pluggable.

I think a deployment is an explicit step though. In most circumstances 
you want to tag what version exactly you're deploying of things.

> Perhaps I just don't understand what you mean by baking the egg but
> usually the stuff I code and then launch on a server is stuff in the
> company svn rather than eggs.

It's very easy to make an egg (or a source tarball, usually you'd want 
that, but it can be treated similarly):

python2.4 setup.py sdist

and grokdeploy can automate this.

> I think we have to be careful to not get too technical on this as it
> might distract from what Grok is all about. A good suggested process
> might help more. It's already a problem that to make a site in Grok
> you don't just have to learn Grok you have to learn Buildout AND Grok
> and sometimes you have to learn vritualenv, easy_install and how eggs
> work.

Yes, I agree it should be easy. This is all about making deployment 
easier though. We want to be able to say: if you want to deploy your 
project, this is how you do it:

* create a tag in your version control system

* checkout the tag

* run bin/buildout to create grokdeploy (or you can install it 
centrally, you can then skip this step)

* bin/grokdeploy

And this'll upload a new version of your application to the server, 
restart it, etc.



More information about the Grok-dev mailing list