[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.
Regards,
Martijn
More information about the Grok-dev
mailing list