Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let's deploy via Git

coderwall.com

Post reply on HN
Print view View original

21–30 of 113 posts

Re: Let's deploy via Git

#21

Post by Aqueous »

tux1968 wrote: post #4
kaoD wrote: post #3

Earlier quoted context omitted.

I agree on the configuration issue, but you can export the working tree[1] in the hook to avoid including the Git history (and in fact it is a sensible choice). The configuration can be handled in the post-receive hook too. I advise against using Git as a deployment tool for serious development (you should use Puppet instead), but for quick hacking and personal projects it's perfectly fine. [1] http://stackoverflow.c…

When you Git push to a live server as the article in question suggests you're sending the entire repo history not just the latest commit. The remote hook only checks out the latest change, but the entire history is sitting right there on the live server. Which is silliness in most cases. As is suggested in the SO article you link, it's more appropriate to locally export the version you want to deploy and use ssh (or…

In this example they are checking out into a work tree that is detached from the central repo, which is bare (or could be.) Therefore there is no .git directory in the work tree and the history is inaccessible from the outside world. I don't see how having the entire history sitting in a private directory on the server is silly, as long as only you can access it.

Honestly we are just talking about transferring files here. However you automate it, as long as it gets the files from point a from point b, is fine. I happen to find it most convenient to use git since that is how I send and receive code changes everywhere else, and it seems foolhardy to introduce another file transferring tool without a really good reason why. Moreover it lets me very easily tell exactly what revision is sitting on the server, and also causes me to pause before I push. It is also really easy to integrate git, through hooks, with a continuous integration setup.

Re: Let's deploy via Git

#22

Post by jebblue »

I'm trying git to get my feet wet with it but man this looks way complicated to me. I didn't even know about "git config" or even that there was a checkout command for git. I usually cd into the directory I want to turn into a repo and use "git init" then after changing files, run gitk or if in Eclipse I use EGit. I'm not even sure what happens in gitk when I do a commit, is it that long "push master origin" stuff? Does that mean master is my local repo and master origin is like the overall master? I guess with SVN it's clear even at the command line but with git there are just so _many_ options. Then there's custom scripts to make all this work? I'll stick with scp or rsync for distribution for now. The author might want to look into Hudson or Jenkins, they work wonders.

Re: Let's deploy via Git

#24

Post by krapp »

FTP still works. FTP isn't 'broken.' This 'replacement' adds huge unnecessary complexity and doesn't work on nearly as many servers as FTP does (which is all of the servers)

And yes, I have deployed with git, so i'm not speaking out of complete backwards ignorance. I can still see a use for both.

Re: Let's deploy via Git

#25

Post by jakobe »

I'm not sure I like the approach of serving files from your repository. I'm not sure about how git works in detail, but are repository updates even atomic?

When I deploy my website, I use a different approach: My webroot is just a symlink. My deployment script exports the repository to a directory with a unique name for every commit. When the export succeeds, the symlink is updated to point to the new directory.

The advantage: Changing to the new version is instantaneous. If something should go wrong, I can immediately revert by changing the symlink back to the old dir.

Re: Let's deploy via Git

#26

Post by ihodes »

jebblue wrote: post #22

I'm trying git to get my feet wet with it but man this looks way complicated to me. I didn't even know about "git config" or even that there was a checkout command for git. I usually cd into the directory I want to turn into a repo and use "git init" then after changing files, run gitk or if in Eclipse I use EGit. I'm not even sure what happens in gitk when I do a commit, is it that long "push master origin" stuff? D…

Check out the git book here: http://git-scm.com/book

Worth the read if you're interested.

Re: Let's deploy via Git

#27

Post by gboudrias »

In the Drupal community, we're all stumbling over each other to find the best Git deployment strategy. I'm surprised that Git deployment would still be news for anyone. I don't know who this article can reach that's not already competent enough to be using Git (at least for dev).

On the other hand, if your site is just static (HTML/JS) files, I think it makes great sense to use Git to deploy, as there is no configuration to worry about.

Re: Let's deploy via Git

#28

Post by pvnick »

bretthoerner wrote: post #19
pvnick wrote: post #12

This is a pretty neat hack, but not really good for a true production deployment system. Rsync is a far superior alternative. That being said, git should definitely be incorporated into the workflow such that, for example, you have a "live" branch which always reflects what is to be on production frontend nodes. From there you do 1) git pull origin live 2) rsync to live servers 3) build/configure/restart/etc. Set -e…

And why is rsync superior?

Part of my reasoning is that rsync is specifically made for this kind of thing, whereas git is specifically made to synchronize coding among multiple developers. So my argument is partly theoretical and less practical.

But for an argument based in pragmatism, rsync has tools such as the --delay-updates flag, which allows your entire deployment procedure to become a pass-or-fail atomic operation. This kind of assurance slows my hair loss as a systems administrator. AFAIK git has no such tools, but I'm certainly open to being corrected.

Re: Let's deploy via Git

#29

Post by mark_l_watson »

pvnick wrote: post #12

This is a pretty neat hack, but not really good for a true production deployment system. Rsync is a far superior alternative. That being said, git should definitely be incorporated into the workflow such that, for example, you have a "live" branch which always reflects what is to be on production frontend nodes. From there you do 1) git pull origin live 2) rsync to live servers 3) build/configure/restart/etc. Set -e…

I use rsync with a local commit hook. I wrote it up here: http://blog.markwatson.com/2013/06/automating-clojure-web-ap... for Clojure auto deployments and I am starting to use something similar for Meteor deployments.

Re: Let's deploy via Git

#30

Post by RussianCow »

tux1968 wrote: post #14
snprbob86 wrote: post #5

Earlier quoted context omitted.

> There may be situations where you want the entire history of your development to be included on your live server, but often this just isn't appropriate. Are you concerned about being wasteful with disk space? Or is there some other concern here? Some security issue perhaps?

Both reasons. Mostly it's because it seems people are using Git to deploy without a good reason. At least I haven't heard of an advantage enjoyed by those using Git for deployment. There are some obvious disadvantages, so what is the compensation? It seems the only reason is that it's easy to type "git push". But of course any deployment method can be wrapped in an equally easy script command. Okay, I have to admit t…

What are the potential downsides? I've been deploying with Git for over a year and am interested in learning why it's not a good idea.
Post reply on HN