Let's deploy via Git

Post by eru » Mon, Jun 24, 2013, 3:27 AM UTC

contingencies wrote: post #89

Ixiaus wrote: post #79

Earlier quoted context omitted.

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…

Post by zrail » Mon, Jun 24, 2013, 3:43 AM UTC

macnix wrote: post #62

I came up with deliver https://github.com/gerhard/deliver to address this very problem. It's bash utility that automates git-based deploys and comes with pre-built strategies for the most common deployment scenarios: generated sites (think Jekyll), shared (WordPress, PHP etc.), ruby, node-js, S3 etc. I did a talk on it at my London Ruby User Group in March: https://speakerdeck.com/gerhardlazu/deliver

Post by zmmmmm » Mon, Jun 24, 2013, 4:23 AM UTC

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.

Post by zobzu » Mon, Jun 24, 2013, 6:11 AM UTC

contingencies wrote: post #89

Ixiaus wrote: post #79

Earlier quoted context omitted.

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…

Post by Peaker » Mon, Jun 24, 2013, 8:12 AM UTC

eru wrote: post #92

Peaker wrote: post #80

Earlier quoted context omitted.

"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

Change the old passwords?