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

81–90 of 113 posts

Re: Let's deploy via Git

#81

Post by Ixiaus »

jpb0104 wrote: post #70

I'm surprised Fabric [ http://fabfile.org ] has not been mentioned in this thread. I'm not a Python developer but I love Fabric specifically for a tool to handle deploying code. If you feel like a Git deployment is lacking, be sure to check out Fabric, especially for multi-server deploys.

Fabric is great for running commands. But what a lot of programmers do not realize is that deployment is a process. That process involves running automated tests, packaging all of the assets, using package managers to upgrade/downgrade based on versioned release schemes, database migration, post-upgrade scripts, and quick/painless rollback (downgrade) if there's a major blocking bug for users.

Re: Let's deploy via Git

#83

Post by jwilliams »

ohwp wrote: post #15
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?

I once committed my DB settings (Mercurial) and noticed my mistake only later. It's very hard to get it out of the history. Ofcourse it could be fixed but this is one example. Imho version control could be used for deployment but only when you use the release-branch of your project. And ofcourse NEVER put your config in version-control ;)

I'm sure many people have done this - the most prudent thing would be to change the sensitive settings? That would solve your history problem as well.

Re: Let's deploy via Git

#84

Post by tacticus »

kaoD wrote: post #3
tux1968 wrote: post #2

I'm a huge Git fan and use it every day, but Git was never designed as a deployment tool. 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. Also, when deploying to multiple servers you have to invent adhoc methods to handle configuration differences. Even native ssh seems like a more prudent deployment method than G…

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…

Puppet does add some significant runtime lag unless you add in other orchestration tools. additionally if operations include cross host dependencies puppet is probably the wrong tool to use.

Re: Let's deploy via Git

#85

Post by michaelmior »

Peaker wrote: post #80
kyrias wrote: post #69

Earlier quoted context omitted.

If there's anything in your repo history that you don't want a hacker to find you can just remove it and force push.

"Just remove it" is hard, because: * It may be hidden in some old commit (e.g: some password) * You'd need to rewrite all history from that point * Force push doesn't necessarily clean the data from the remote

FWIW, the "hidden in some old commit" problem is easily solvable with git-filter-branch. But the second two points are certainly valid :)

Re: Let's deploy via Git

#86

Post by rdtsc »

ohwp wrote: post #15
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?

I once committed my DB settings (Mercurial) and noticed my mistake only later. It's very hard to get it out of the history. Ofcourse it could be fixed but this is one example. Imho version control could be used for deployment but only when you use the release-branch of your project. And ofcourse NEVER put your config in version-control ;)

> And ofcourse NEVER put your config in version-control ;)

Why wouldn't you want to version your configurations in general? Maybe I am not sure what you mean by "config" but in general version controlled configuration is always good. I even set up git in my etc sometimes to track changes I make to it manually (not in production, on my home machine).

Re: Let's deploy via Git

#87

Post by jasonlotito »

hmind wrote: post #71

And here I was thinking that this was obvious and most people used something like Capistrano... It's shocking to me the amount of people not using some sort of SCM-based deployment method. =P

I'm more surprised that people aren't using something more reliable and proven, like the package manager their system already uses. Why introduce another piece?

Re: Let's deploy via Git

#88

Post by rdtsc »

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.

Second that. I think it only comes with maturity. If there is a small start-up and they have a couple of Ubuntu servers they'd start with just syncing their source repo, running 'make && make installs' by hand via ssh.

After a while if they use python, node or ruby, maybe start generating language specific packages (pip, virtualenv, etc).

Next phase is when the need for upgrade/downgrade transactions comes about, handling transitive dependencies (my package needs another package, which in turn requires a third package to be upgraded, which is a base system package to be upgraded). Now 'make && make install's looks silly and mess up the file system with left-over files. Deployment ssh scripts become a tangled mess and so on. Then slowly they think "It would be cool if there was a system created that can transitively handle package versions, and maybe provide transactions with pre and post install scripts".

If they are lucky, someone will point them to apt or rpms or they'll write a broken version of those things from scratch.

Re: Let's deploy via Git

#89

Post by contingencies »

Ixiaus wrote: post #79
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…

Both Git and Rsync are incompetent deployment tools for many reasons I will not go into in a comment as there are quite a few articles expounding on the virtues of not using your VCS. There are also numerous reasons why rsync is inappropriate too (what if you push up a nasty bug and you have to revert? Op, better go revert to my tagged release then rsync again - this is ugly in comparison to versioned releases combin…

I agree.

Benefits of versioned archives over VCS for deployments: easily checksum and cryptographically sign; easily integrate with existing distribution specific package databases; deploy without requiring a VCS (and all its dependencies, including maintained and accessible VCS repo-hosting deployment infrastructure), probable security and speed benefits of the resulting (ie. minimalist) approach (both at the level of the host and the network).

Personally I use a combination of versioned archives and named and versioned target environments, each of which can be tested both individually and in combination (including regression tests). This works well for me.

Re: Let's deploy via Git

#90

Post by bluetooth »

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…

> but are repository updates even atomic?

No, they are not. During the push, there will be a short amount of time in which some parts of the website will be operating on new code, while others will be operating on old code. If many components are in play (ie using libraries) you may end up breaking things if a new request comes in at the right time.

Post reply on HN