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

41–50 of 113 posts

Re: Let's deploy via Git

#41

Post by pvnick »

avar wrote: post #37
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…

We've been working on moving away from rsync for our code syncing to using Git where I work. I'm not saying there aren't uses for rsync, but your dismissal of git as not being suitable for a "true production deployment system" isn't supported in any way. And stating that rsync was "specifically made for this kind of thing" without comparing any of the trade-offs involved is just appealing to authority. Some things yo…

Thank you for your well-constructed reply. I've updated my original post to reflect my current thoughts.

Re: Let's deploy via Git

#42

Post by mikegirouard »

I use git to deploy about 30 sites and have found it to be a really useful workflow. It's particularly useful over SSH when using key-based authentication.

For my post-receive hook, I always add a tag to mark a deployment:

    git tag deployment-`date +'%Y%m%d%H%M%S'`
You can see all past deployments with a git log:

    git log prod/master --oneline --decorate
On all my developer machines, I have them add a `git-deploy` script to their $PATH, which looks a little something like:

    #!/bin/bash
    git push $1 +HEAD:master
    git fetch $1
You can just run `git deploy prod` (assuming your deployment repository is named 'prod').

The extra `git fetch` will pull down the auto-generated tags so you can see them locally w/a simple `git tag`

Edit: Forgot to mention, that since git ships w/a bash shell for Windows, most of this should work for Windows-based dev setups as well.

Re: Let's deploy via Git

#43

Post by AgentIcarus »

robinson-wall wrote: post #34
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.

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

Re: Let's deploy via Git

#44

Post by Marc_Paradise »

RussianCow wrote: post #30
tux1968 wrote: post #14

Earlier quoted context omitted.

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.

Security.

Are you 100% sure that there is nothing you are exposing via your git repo that you want to keep away from the person who manages to hack your server or discover some means to reach the repo externally?

Getting hacked is not inevitable, but if you treat your systems as if it were you'll be a lot safer if it does ever occur.

Re: Let's deploy via Git

#46

Post by tux1968 »

avar wrote: post #37
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…

We've been working on moving away from rsync for our code syncing to using Git where I work. I'm not saying there aren't uses for rsync, but your dismissal of git as not being suitable for a "true production deployment system" isn't supported in any way. And stating that rsync was "specifically made for this kind of thing" without comparing any of the trade-offs involved is just appealing to authority. Some things yo…

You've described some admirable utility that can be achieved by using Git. However, it can all be accomplished with other tools and without needing the entire deployment history stored on each production machine.

As for your comment about being "back to comparing files", that's all Git is doing internally anyway. You can do the same with other deployment tools and sha1 hashes etc.

Re: Let's deploy via Git

#47

Post by viraptor »

krapp wrote: post #24

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.

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.

Re: Let's deploy via Git

#48

Post by avar »

tux1968 wrote: post #46
avar wrote: post #37

Earlier quoted context omitted.

We've been working on moving away from rsync for our code syncing to using Git where I work. I'm not saying there aren't uses for rsync, but your dismissal of git as not being suitable for a "true production deployment system" isn't supported in any way. And stating that rsync was "specifically made for this kind of thing" without comparing any of the trade-offs involved is just appealing to authority. Some things yo…

You've described some admirable utility that can be achieved by using Git. However, it can all be accomplished with other tools and without needing the entire deployment history stored on each production machine. As for your comment about being "back to comparing files", that's all Git is doing internally anyway. You can do the same with other deployment tools and sha1 hashes etc.

   > it can all be accomplished with other tools
Sure it can be accomplished with other tools, but if Git is sufficient introducing other tools just increases the complexity of your stack, and the complexity of e.g. validating that a Git tag corresponds to what claims to be rolled out as that tag.

   > and without needing the entire deployment history stored on each
   > production machine.
This is a constraint a lot of people seem to think they need but they don't actually need. If someone gets your current checkout they'll have current code / passwords (if you accidentally checked in a password but removed it you should change that password). Getting the code history will just satisfy historical curiosity. Hardly a pressing concern for an attacker.

   > As for your comment about being "back to comparing files", that's
   > all Git is doing internally anyway. You can do the same with
   > other deployment tools and sha1 hashes etc.
Yes, but the point is that it just gives you that for free without you having to hack anything extra on top of your syncing mechanism.

You'd be pleasantly surprised how much checking/validation/syncing logic that you have to write around e.g. rsync when syncing a Git repo just disappears entirely if you just use Git to sync the files.

Re: Let's deploy via Git

#49

Post by krapp »

viraptor wrote: post #47
krapp wrote: post #24

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.

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" either. All of my servers have ssh/scp available and will never have ftp. I stand corrected.

It is good to actually see the arguments against FTP at least.

Re: Let's deploy via Git

#50

Post by avar »

mikegirouard wrote: post #42

I use git to deploy about 30 sites and have found it to be a really useful workflow. It's particularly useful over SSH when using key-based authentication. For my post-receive hook, I always add a tag to mark a deployment: git tag deployment-`date +'%Y%m%d%H%M%S'` You can see all past deployments with a git log: git log prod/master --oneline --decorate On all my developer machines, I have them add a `git-deploy` scri…

You might be interested in checking out git-deploy. It's a tool we wrote to manage tag creation and completely pluggable rollouts/rollbacks with sync hooks you write: https://github.com/git-deploy/git-deploy

It's basically a more advanced version of what you're doing.

Post reply on HN