Show HN: better software deployment with Git | Hacker News Reader

Show HN: better software deployment with Git

github.com

66 pointsarnoooooo30 comments

Git is a source version control system. Why does everybody keep trying to use it as a deployment tool?

I don't know, but it's a very annoying trend.

I appreciate the work that has gone into this code, but if you want to deploy using source control then you should really be looking into continuous integration and deployment.

I'm not trying to use it as a deployment tool, I'm building a lightweight deployment tool over it and SSH.

I think the simple answer to this one is that it's a universal deployment tool. Like it or not, anyone who uses git can use it.

If I'm working on a Python project, I could possibly create a Fabric file to help automate the deployment. Anyone working on the same project would have to install Fabric, and figure out any quirks it has.

The same then applies to every other language. They tend to recreate deployment tools in their own language to solve the exact same problem. Capistrano for Ruby, etc. Everyone has to learn the deployment process for each different project.

Using git as a deployment tool means that the only person who has to worry about the deployment process is the one who creates the server side commit hook/push scripts. All the complexity is taken away, they just have to say "push to git@example.org" and all the magic behind it is taken care of.

It's universal between all projects. If I'm running a PaaS, all I have to tell my users is to put files in a specific place, add a config file, push to our servers. Without this, users of every language might need specific deployment tools, or be forced to use a generic one which might not suit their needs.

Because it works very well and the tasks aren't really all that different? Push changes, synchronise files across machines.

That's a really odd comment to make. Surely automating the steps to deployment is a good thing.

Git has hooks for kicking off processes, its extensible, deployment scripts don't alter the core of git. What's the problem with evolving something?

Not odd. OP Is noting that this seems to confuse "make" with "make install". This leads to problems.

Because my repo is clean whilst my working folder is messy.

Because any application that can copy files over a network is eventually used as a deployment tool. I'm sure there's a netcat deployment tool out there somewhere. ("Hey look, with the -e option I can run a script to process the deployment on delivery!")

These two things typically go hand in hand. I personally use git to version my deployments. So, I'll check something into git, and then have it do a deployment via a git post commit hook. This is very handy, in that I have a history of what was deployed along with the changes. I can also easy revert changes and they get pushed out. So, we are distilling a deployment (which typically has many steps) into a 'git push' workflow.

Have you not thought of using a CI tool to do this for you, on push to a select branch? This is basically what they do.

As a sysadmin, seeing this kind of stuff gives me The Rage(tm). Don't fight the distro - your distro of choice (Debian, RedHat, BSD, -buntu, whatever) already HAS ways of deploying your software. It even plays nice with interdependencies between different packages, allows custom scripts at different stages of deployment, etc. They're not perfect, but they ARE standard. Learn them, use them, love them, and if there's anything particularily egregious about some aspect of them, they're open source so you can submit patches. Literally every job I've ever had as a sysadmin has started with "...so the developers rolled their own software distribution tool and we're learning the hard way that we've blown a sizable hole in our collective foot with it". Working with developers to apply a suitable dose of RPM or DEB magic (99% of the time, these systems are Linux-based and speak one of those two packages) solves the problem, and everyone agrees that it's a better solution.

Don't fight the distro, people. They've hit all of your problems harder, sooner, and with more edge-cases than you can care to imagine.

Does it still have the `.git` folder? If so, I'll stick to writing regular build scripts, as nice as this seems. I also want to push a snapshot of a build artifact (sort of, it's PHP after all) - not sending a few folders, sending commands to the remote server to execute, etc.

Anyone have a better way of achieving what I want that doesn't require my hacked together `build.php --deploy` script?

I like Fabric: http://docs.fabfile.org

My largest system builds and deploys with Fabric. We deal with multiple load-balancers with unique content, and it works perfectly. I use it for a master control Python script that watches/adds/etc our servers and our data.

Brilliant. Cheers, I've been looking for something like this for ages. Sick of my hacky bash and PHP scripts.

Yes it does, by design: I want to be able to check the integrity and diff easily on a delivered version, with or without the tool.

Whilst I agree with your objectives and would love a tool that does this. I have not done so myself because of security problems with having .git in the website folder. I'll continue to use git's hooks to copy the files as I push them to the server.

Right now, your source is potentially downloadable via the web, if a developer accidentally places a password in the code and then later reverts the change, its still in the history for someone to find. Plus they get the ability to rip off your work because you've made it public. Or perhaps just scan it for flaws to exploit.

I know what your going to say, that you can mitigate these problems with a simple configuration change. However is everybody that you give the code to going to do that on every server they deploy?

What nextw33k said! It's not an issue for me: I _know_ the gotchas when dealing with this stuff (that's why I asked!), but the people I hire in the future might not.

I only know about it because I've been burned by it in the past!

I have to admit I missed this aspect. I've only delivered projects where the main folder was not web accessible until now.

I agree that this is an issue, I'll have to see if I can find a clever way to get around this.

I had a feeling that was the case :) I will use this for smaller personal things for sure, but I think I've got to handle my startup slightly differently; I've got a lot of security things I have to be wary of!

Thanks so much for this tool btw, I really like the look of it!

I use ansible and rsync for my personal site. I don't know how well that would work for something more complicated than static files, but I'm guessing just fine.

Wait, what's wrong with the .git folder? I'm not sure I'm clear why that's an issue...

You don't want to accidentally make it public, which might happen if your webserver points to the root of the git working copy.

Capistrano is great. https://github.com/capistrano/capistrano

It's a bit much at first, but once you realize that it's basically just a build file with some handy functionality baked in, it's very useful. Here's an example of a deploy script for deploying a git repo to a single machine:

    set :application, "Project Name"
    set :repository, "git@github.com:project/project.git"
    set :use_sudo, false
    set :user, "deploy_user"
    set :shared_children, ["list", "of", "directories/to", "symlink/rather/than/copy"]
    set :copy_exclude, [".git/*"]
    set :scm, :git
    set :branch, "master"
    set :deploy_via, :remote_cache
    set :keep_releases, 5
    set :deploy_to, "/path/to/deploy/to"

    server "1.2.3.4", :app, :web, :db

Then you just run `cap deploy` and you're deploying. `cap rollback` instantly rolls back to the previous revision of your code. That deploy script keeps 5 releases and manages a symlink that points to the current release. The git repo is kept checked out, and then is updated and copied to a release directory, so you have multiple separate snapshots of your application on hand.

It's also extremely extensible; we use it to do asset pre-builds, send deployment notices to Hipchat and NewRelic, flush caches, restart background workers, and the like.

This looks similar to fleet[1] (which is awesome, btw). git-deliver looks a bit more complicated, though designed for more than just Node deployments.

[1] https://github.com/substack/fleet

Seems like a great tool, I will definitely give it a try on my next project. So if I understand well, Git doesn't have to be installed on the production server(s), only SSH access is needed, right?

No, Git is required on the server(s). It's used for a few things, the most important being the creation of each delivery clone.

What's the difference with capistrano?

It also looks like using ansible + git. However, also gitflow is just a clever use of git branches, but having a standard way of doing things using simple existing tools (git + ssh here) defined by someone who has studied the problem is very valuable to other people who has similar issues, but didn't study the case yet.

Reply on news.ycombinator.com