

Google App Engine now supports Git Push-To-Deploy - AndrewDucker
https://developers.google.com/appengine/docs/push-to-deploy

======
masto
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.

~~~
ImJasonH
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)

------
LeafStorm
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.

~~~
zimbatm
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

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

~~~
BarkMore
This comment [https://groups.google.com/d/msg/google-appengine-
go/iV5UkqD5...](https://groups.google.com/d/msg/google-appengine-
go/iV5UkqD5iKM/RfW_rKtSQ9IJ) implies that it will happen for Go.

------
the1
[http://gitolite.com/the-list-and-irc/deploy.html](http://gitolite.com/the-
list-and-irc/deploy.html)

~~~
crb
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.

~~~
ImJasonH
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.

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

~~~
mehta
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.

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

~~~
levosmetalo
pure ad hominem. the "fact" he's an former/current MS employee doesn't make
his personal claims any more valid or invalid, and thus is irrelevant for the
discussion.

on a side note, people on hn are outraged by NSA spying on us here, but
perfectly happy to search, collect, process, organize and publicly disclose
"data" about other people here.

~~~
blibble
can you point out the part where I attempted to discredit his point because
he's an MS employee, even discussed his point at all?

because I can't see it.

~~~
jader201
I would say because it was in response to a question about why he preferred
one over the other.

