4 ms·

Show HN: better software deployment with Git

66 points by arnoooooo 13y ago

laurent123456 13y ago
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?
- arnoooooo 13y ago
  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.
jeantristan 13y ago
What's the difference with capistrano?
- tigroferoce 13y ago
  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.
jafaku 13y ago
Git is a source version control system. Why does everybody keep trying to use it as a deployment tool?
- EnderMB 13y ago
  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.
- arnoooooo 13y ago
  I'm not trying to use it as a deployment tool, I'm building a lightweight deployment tool over it and SSH.
- SudoAlex 13y ago
  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.
- endeavour 13y ago
  Because it works very well and the tasks aren't really all that different? Push changes, synchronise files across machines.
- nextw33k 13y ago
  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?
  - tutufan 13y ago
    Not odd. OP Is noting that this seems to confuse "make" with "make install". This leads to problems.
- thruflo 13y ago
  Because my repo is clean whilst my working folder is messy.
- peterwwillis 13y ago
  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!")
- WestCoastJustin 13y ago
  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.
  - EnderMB 13y ago
    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.
girvo 13y ago
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?
- drcongo 13y ago
  I like Fabric: http://docs.fabfile.org http://docs.fabfile.org
  - jamesroseman 13y ago
    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.
  - girvo 13y ago
    Brilliant. Cheers, I've been looking for something like this for ages. Sick of my hacky bash and PHP scripts.
- arnoooooo 13y ago
  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.
  - nextw33k 13y ago
    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?
georgecalm 13y ago
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 https://github.com/substack/fleet
lwhalen 13y ago
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.

66 points by arnoooooo 13y ago

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?

arnoooooo 13y ago
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.

jeantristan 13y ago

What's the difference with capistrano?

tigroferoce 13y ago
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.

jafaku 13y ago

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

EnderMB 13y ago
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.
arnoooooo 13y ago
I'm not trying to use it as a deployment tool, I'm building a lightweight deployment tool over it and SSH.
SudoAlex 13y ago
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.
endeavour 13y ago
Because it works very well and the tasks aren't really all that different? Push changes, synchronise files across machines.
nextw33k 13y ago
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?
- tutufan 13y ago
  Not odd. OP Is noting that this seems to confuse "make" with "make install". This leads to problems.
thruflo 13y ago
Because my repo is clean whilst my working folder is messy.
peterwwillis 13y ago
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!")
WestCoastJustin 13y ago
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.
- EnderMB 13y ago
  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.

girvo 13y ago

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?

drcongo 13y ago
I like Fabric: http://docs.fabfile.org http://docs.fabfile.org
- jamesroseman 13y ago
  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.
- girvo 13y ago
  Brilliant. Cheers, I've been looking for something like this for ages. Sick of my hacky bash and PHP scripts.
arnoooooo 13y ago
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.
- nextw33k 13y ago
  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?

georgecalm 13y ago

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 https://github.com/substack/fleet

lwhalen 13y ago

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.