4 ms·

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

by jafaku 13y ago

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.

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

by jafaku 13y ago

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.

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.