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

51–60 of 113 posts

Re: Let's deploy via Git

#51

Post by gkop »

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…

> _why_ you would want to use git-push

Many of us like to have some recent past releases sitting on the production servers in order to make instant rollbacks if we discover a bug after the code has been deployed. Git provides that for free.

Re: Let's deploy via Git

#52

Post by crististm »

Yeah, Python and other technologies are also 90's or even older - what is your point? Proven technologies that work are belittled to promote today's agenda?

I would tend to dismiss this kind of articles and suggestions even if they are OK - only because they promote by appeal to a fashion.

Re: Let's deploy via Git

#53

Post by gkop »

jakobe wrote: post #25

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…

You can combine this approach with updating the code with a git pull to get all the benefits of git. Capistrano, the conventional Ruby deploy script, does this by default.

Re: Let's deploy via Git

#54

Post by viraptor »

krapp wrote: post #49
viraptor wrote: post #47

Earlier quoted context omitted.

Actually it is broken by today's standards. No encryption, two connections, nat issues, no standard (everyone does best-effort output parsing), etc. It doesn't work on "all of the servers" either. All of my servers have ssh/scp available and will never have ftp.

No encryption What about ftps? two connections Not a problem if you're only occasionally updating one site at a time, though I'd agree it doesn't scale up the way git would. nat issues, no standard valid points. I've never had issues with either but I don't work on the kind of projects a lot of HN users do, so I really tend to only care if it stripped the line breaks or not. it doesn't work on "all of the servers" ei…

Not sure what's the current state of ftps deployment, but when I checked mid-200X, it was still a very rare occurrence. Maybe it's a bit better now.

It's hard to find out from google, because they claim I want to look for "ftp" rather than "ftps" and they're the same thing :/

Re: Let's deploy via Git

#55

Post by Tobu »

AgentIcarus wrote: post #43
robinson-wall wrote: post #34

Earlier quoted context omitted.

> Install with native package tool I'm sad that so few people seem to build native OS packages for deployments. My build system creates a release package and sticks it in an apt repo, then puppet installs latest version of package when it runs.

I've just started looking at this sort of thing - can I ask what technology you decided on for the apt repo? (I'm especially interested in whether the restriction most of them impose on having multiple versions of a package is something you are dealing with).

I use mini-dinstall for repos. Multiple versions would complicate things however; I'd probably do it by combining multiple suites.

Re: Let's deploy via Git

#56

Post by jahewson »

lifeisstillgood wrote: post #13

Aaargh ! Build on a build server Scp to live server along with generated config Install with native package tool and hook into native service manager Use salt / puppet / chef to do everything after initial build on your target servers. Be nice.

Yes, exactly. Some of us still have compilers! Or more than one git repo.

Re: Let's deploy via Git

#57

Post by Tobu »

cpa wrote: post #33

And add some directives to your http server to not serve your .git directory, too!

I had good hopes when I saw `core.worktree`, but that was just cargo-culting. The right way to do it is to set the worktree to an outside location.

Re: Let's deploy via Git

#58

Post by michaelmior »

pvnick wrote: post #28
bretthoerner wrote: post #19

Earlier quoted context omitted.

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 assuranc…

As mentioned in another comment, you can get the rough equivalent of --delay-updates with git fetch followed by git reset or git merge.

Re: Let's deploy via Git

#59

Post by cleaver »

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…

Anywhere that I have a say in the matter, FTP is disabled. I've been a fan of rsync for years and have a bunch of scripts that can make the whole process seamless. That said, I'm starting to be won over by git deploys.

The reason I've started to like git is deletes. You can handle them with rsync:

rsync --delete

The problem is that some projects have content uploaded in the same file tree (simple CMS installs). This might not be an issue if it was structured differently (symlink to another directory), but sometimes it's what I have. Using "rsync --delete" would remove newly uploaded user content. Yeah, I could use the "--exclude" option as well.

With git, I can just "git rm ..." and the file will be removed on deploy. Content can be mixed in the same tree and hidden with a .gitignore file. File content can be managed separately with rsync, if that's the best way. Just not FTP. Please.

Post reply on HN