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.
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)
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
The possible existence of personal bias for/against a particular company/technology/person is useful. I don't see how implying that the OP is an employee of a competitor of Google is an ad hominem attack, unless you consider disclosing association wich can cause bias/preference in the topic at hand an attack. I see it merely as a framing device.
> 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.
Do you really fail to see the difference between an individual using information that has been made voluntarily public too check somebody up and the systematic monitoring of all public and private communications of people around the world by a single entity?
