3 ms·

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

by the1 13y ago

estebank 13y 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 13y 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 13y 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.
- ImJasonH 13y 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.

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

by the1 13y ago

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

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 13y 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 13y 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.

ImJasonH 13y 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.