Google App Engine now supports Git Push-To-Deploy

https://developers.google.com/appengine/docs/push-to-deploy

by AndrewDucker • 13 years ago

135 24 13 years ago

developers.google.com

Almost a clone of the Windows Azure functionality, but not as good.

mehta• 13 years ago

Can you elaborate a bit? I have not used either and would love to know what is different between the two and why you prefer one over the other.

Edit: I saw a few comments about original commenter being a MS employee. To be clear, I am a Google Employee (and ex-msft employee) :). But who our employers are is really besides the point. My question about pros and cons still remains.

blibble2• 13 years ago

comment history and a bit of googling would suggest he's an MS employee...

jsolson• 13 years ago

I went and took a look at the walkthrough for GAE[0] and Azure[1].

Azure offers the ability to push to, say, GitHub and have that result in an Azure deployment. For some users that might be a really nice feature, as it ensures they don't end up with code deployed that can't be browsed in their "authoritative" code browser.

Of course, they're both very similar to what Heorku has done more or less since its inception.

[0] https://developers.google.com/appengine/docs/push-to-deploy

[1] http://www.windowsazure.com/en-us/develop/net/common-tasks/p...

the1• 13 years ago

http://gitolite.com/the-list-and-irc/deploy.html

estebank2• 13 years ago

This new feature makes it easier to do this, as the post-commit hook only has to push to another repo, as well as making it dead simple for people on smaller teams to do use this without having to implement anything beyond adding an extra remote.

I had a similar setup in place, now I can happily delete most of that code and configuration files.

oneandoneis2• 13 years ago

I'm particularly impressed by the way they've taken a tool that shouldn't be used for deployments; quoted the gurus who've said "don't use it for deployment"; and gone ahead with creating ways to use it for deployment.

Maybe the next project can be a tool to automate rebasing published history and force-pushing it to origin? People are always saying you shouldn't do that either.

crb• 13 years ago

That post seems to talk about how to implement this functionality yourself - as in, what the server should do when someone pushes new changes to it.

In the case of App Engine, Heroku, Azure etc, that is all abstracted away from you - as is, in many cases, the concepts of binaries. You just package up and upload some code somehow, and their "mesh" decides where to deploy it and how to run it.

(I know Heroku gives you a little more control over this; with App Engine, you get a config file and a number of instances you can tweak, and that's about it in the general case.)

This is so far available for Python and PHP - not Java or Go.

ImJasonH2• 13 years ago

Exactly. While the article makes very good points about what you want from a general-purpose Git deployment script, deploying to App Engine is not quite the same, since there is no Git client on the server pulling changes directly, so you avoid the problems addressed by all four points.

App Engine creates new app instances when you deploy, so there's no need to care about deleted files, tracked/untracked files on the server, and so on.

LeafStorm• 13 years ago

The problem with using Git push to deploy is that when you're first setting up your deployment, if you make a mistake in the settings, you can't amend the commit to fix it, because it's already been pushed - so the mistake stays there for all eternity. And if you try to fix it and your fix doesn't work, that's another bad commit.

I deployed my first project to Heroku a few weeks ago, and now my project history has a handful of permanently unremovable junk commits, which I made solely to force Heroku to rebuild my app.

schrodinger2• 13 years ago

Just use git push -f. Or just push from a branch.

zimbatm• 13 years ago

Here is how I work on heroku, use a branch, rebase and force push to clean your commit logs:

    git checkout -b heroku-setup
    # make some commits
    git push -u heroku heroku-setup:master
    # oops, something was wrong
    # make some more commits
    git push
    # ok, everything is working
    git rebase -i origin/master
    # squash/remove commits
    git push -f
    # test one last time
    git checkout master
    git merge --no-ff heroku-setup
    git push

tokenizerrr• 13 years ago

You can rewrite history. This is a bad idea if other people are collaborating on your project, as the new history will be mismatched with theirs. It can still be done safely when properly collaborated, or if you're alone just go for it.

http://gitready.com/intermediate/2009/01/31/intro-to-rebase....

X-Istence• 13 years ago

So long as the target you are deploying too can't also get pulled from in the mean time you can amend commits all you want and push as often or as little as you want.

There is no need for junk commits.

masto• 13 years ago

I guess this is not intended to be your "main" repository? Something about the idea of deploying on push to master seems off to me. I have been thinking about doing this myself, but it would either be a special release branch or a tag that would trigger the deployment. However, I'm still not convinced it's a good idea; I think it's the wrong tool for the job. My preference is to have a continuous integration server produce and archive builds, and a separate tool for promoting those builds through the development/qa/staging/production pipeline. Using your source control tool for deployment is like a badly structured class that tries to do multiple unrelated things and suffers from tight coupling. Source control, build systems, and deployment tools should be independent, with clean interfaces between them. The component responsible for deploying a build shouldn't care where it came from or how it was built.

schrodinger2• 13 years ago

Don't use it as your main repository, that's all. Store your true history in another location, and use this as a way to reliably sync your files to the hosting environment. Setting up a CI environment with automated deploys is probably better, but this is great for small projects that don't warrant that level of configuration. Also, if you do go the CI route, this could just be how the final step of copying files works, rather than rsync or something.

ImJasonH2• 13 years ago

Alternatively, deploy to a non-default serving version of the app. Then, when you push/deploy, you can go to the non-default version, check it's right, then promote it to default.

This flow isn't as smooth as it could be, certainly, but we're hoping it could be useful for small teams or new users. And we'd love to hear your ideas about how to make this even more useful, this is an area under very active development (thus the Preview label)

talloaktrees• 13 years ago

Python and PHP only. I guess this won't ever happen for Java and Go because of the need to compile.

BarkMore• 13 years ago

This comment https://groups.google.com/d/msg/google-appengine-go/iV5UkqD5... implies that it will happen for Go.

pkulak• 13 years ago

I don't see why you can't just have a post-commit hook to compile.

Google App Engine now supports Git Push-To-Deploy

Related Stories