Let's deploy via Git
coderwall.com
Let's deploy via Git
1–10 of 113 posts
Re: Let's deploy via Git
#2I'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 Git. This smacks of using the closest hammer at hand, rather than choosing the best tool.
Re: Let's deploy via Git
#3I'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.com/questions/160608/how-to-do-a-git-ex...
Re: Let's deploy via Git
#4I'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…
When you Git push to a live server as the article in question suggests you're sending the entire repo history not just the latest commit. The remote hook only checks out the latest change, but the entire history is sitting right there on the live server. Which is silliness in most cases.
As is suggested in the SO article you link, it's more appropriate to locally export the version you want to deploy and use ssh (or whatever) to transfer it to the live server. Nobody ever seems to try to justify _why_ you would want to use git-push, they just go about explaining how you do it.
Re: Let's deploy via Git
#5I'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…
> 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?
Re: Let's deploy via Git
#6The issue here is that there is still numerous web hosts who don't grant you SSH access, so you're not able to set up any git repository there anyway and are still stuck with FTP. Hopefully this will go away soon, or at least more in the direction of Heroku and the likes.
Re: Let's deploy via Git
#7The issue here is that there is still numerous web hosts who don't grant you SSH access, so you're not able to set up any git repository there anyway and are still stuck with FTP. Hopefully this will go away soon, or at least more in the direction of Heroku and the likes.
Which web hosts are they and what advantages do they have over web hosts that do grant ssh access?
Re: Let's deploy via Git
#8The issue here is that there is still numerous web hosts who don't grant you SSH access, so you're not able to set up any git repository there anyway and are still stuck with FTP. Hopefully this will go away soon, or at least more in the direction of Heroku and the likes.
Which web hosts are they and what advantages do they have over web hosts that do grant ssh access?
Take Hetzner (large German provider) as an example - while they do offer managed servers and root servers, those are much more expensive. I'm not advocating the use of such products, but merely pointing out that they're still around a lot.
Re: Let's deploy via Git
#9I'm planning on writing about this in more depth later, but this is essentially the route every cloud hosting company is taking right now and I think it's a bad to only allow that kind of deployment.
Don't get me wrong, I love Capistrano, git deploy hooks, ruby gems that do deploys (heroku), but most cloud hosts are only offering this mechanism to deploy apps. FTP became popular because of the ease of use for designers and webmasters. You don't always need to deploy your entire application for simple changes. Another big one is the ajax file editor in the browser.
For trivial changes a simple file change would suffice. When you do an entire deploy for app like this, depending on your dependencies and payload, it could take a long time. What if you had the wrong price and need to make a change immediately? Of course maybe now there are multiple environments which play a factor too.
I do realize that was before we had multiple web servers running the app and that is part of the reason, but there are still ways to make it work (file mounts).
I'm hoping more deployment options in the future and that cloud hosts realize the need is still there from traditional hosting.
Re: Let's deploy via Git
#10I personally prefer git-ftp. It is common that ssh is still only luxury.