Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is clever, but the idea of serving a website directly from a repository makes me very uncomfortable. If you already have git and ssh access on a server, then you probably have rsync access, as well. I simply include a Makefile in my repo with a publish target that runs a command like this:

    rsync -avz --exclude '*.swp' --delete site/ $(WEBUSER)@$(WEBHOST):site/
This way I'm only putting the necessary files on the server and transferring changes is incredibly fast and secure (ssh is used by default).

In rare cases where I need to deploy from a repo on the server, I'll clone it to the remote host and use rsync locally to copy the files. But I still avoid serving directly out of the repo. There's too much sensitive information in version control to even risk exposing it during a misconfiguration.



I'm curious what kind of sensitive information you're concerned about exposing. I don't mind deploying with rsync--in fact, I'll do it quite a lot when the remote host lacks git--but I'd usually prefer to use git where possible.

I typically deploy with a similar setup that you described, but instead of rsync'ing the files locally I just make a clone of the repo and serve that. Though it is another step to fetch/merge, it stops me from losing any changes that someone did to production without telling me.

I only recently used Capistrano to deploy a project and it was very satisfying, so I'm gravitating towards that as my default deployment method.


> I'm curious what kind of sensitive information you're concerned about exposing

+1. Secrets should not be in your VCS repo. I'd guess the parent is talking about user/pass or pub/priv key creds.

I really wish "we" had better tools for passing around config, and secrets in particular. Chefs data bags are close, but I still don't want the master knowing my secrets.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: