Balls of steel deployment
Let's deploy via Git
101–110 of 113 posts
Re: Let's deploy via Git
#102Re: Let's deploy via Git
#103git push/pull is easy, but there's no getting around the fact that Git is a distributed version control tool, not deployment software. Using Git for deployment is probably fine for simple deployments where you're just getting a bunch of static files onto a single box, but as soon as you stray into the realm of non-trivial web application deployments then things change. Factors like database migration, dev/prod enviro…
My thoughts exactly. This workflow is nothing more than hacking Git using post-commit hooks to do something it was never built for.
If you want to deploy using Git then the smart thing to do is to use one of the many continuous integration tools out there that were built specifically for this kind of workflow. I use TeamCity to run my tests and to build/deploy my website whenever I push to my default branch. This works really well for some of my sites, and although I'm looking for a way to refine this so I can also deploy database changes between local/staging/web servers I can't think of a better way of doing this.
Re: Let's deploy via Git
#104Or use Heroku.
That's no way to fix a problem
Re: Let's deploy via Git
#105Terrible idea..
Re: Let's deploy via Git
#106This is a pretty neat hack, but not really good for a true production deployment system. Rsync is a far superior alternative. That being said, git should definitely be incorporated into the workflow such that, for example, you have a "live" branch which always reflects what is to be on production frontend nodes. From there you do 1) git pull origin live 2) rsync to live servers 3) build/configure/restart/etc. Set -e…
Anywhere that I have a say in the matter, FTP is disabled. I've been a fan of rsync for years and have a bunch of scripts that can make the whole process seamless. That said, I'm starting to be won over by git deploys. The reason I've started to like git is deletes. You can handle them with rsync: rsync --delete The problem is that some projects have content uploaded in the same file tree (simple CMS installs). This…
What's wrong with exclude and exclude-from? Using git rm without file manager integration - can be a little thorny.
Re: Let's deploy via Git
#107Earlier quoted context omitted.
I think the main problem is unknown exposure: Do you audit all old commits to find any sensitive data?
Shouldn't you audit all commits in any case?
So, you have two choices:
1) You can go through the trouble of identifying and resolving all the edge cases that you encounter when using Git as a deployment tool. Keeping in mind that one of those may result in an embarrassing security disclosure. Woops.
2) You can use a deployment tool that was developed for that purpose, has existed for years, and has had many sets of eyes on it; many of which are inevitably more experienced than you. And you still may end up with an embarrassing security disclosure, but the chances are better that you'll hear about it through responsible disclosure channels first, rather than waking up at 3 AM to the voice of your boss/client asking why the site is redirecting users to buy Viagra at a discount.
A bonus third choice:
3) You look at existing deployment tools and ask yourself "I wonder why they do that?" Then, maybe ask around a bit. Once you've got a good idea of all idiosyncrasies involved with deploying software, then you embark upon building your own tool. I think you'll find that simply `git pull`ing from your httpd document root and `rm -R`ing the .git/ directory won't be your final solution.
Re: Let's deploy via Git
#108Earlier quoted context omitted.
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…
> _why_ you would want to use git-push Many of us like to have some recent past releases sitting on the production servers in order to make instant rollbacks if we discover a bug after the code has been deployed. Git provides that for free.
This is almost exactly what Capistrano does. What's hilarious is that this entire thread reads like a discussion that could have lead to the development of Capistrano.
* Capistrano can deploy via git (it uses export)
* Capistrano keeps a configurable number of releases around in case you need to rollback
* Capistrano provides an ordered task system with before/after hooks at every one of its pre-defined tasks
* Capistrano can be just as lightweight as using git to deploy:
cap deploy
git push
* You may not need all the stuff that Capistrano provides today, but as your project grows, you will need it. Why waste your time with a compromised deployment hack when better tools are available and easy to use?
Re: Let's deploy via Git
#109Earlier quoted context omitted.
I think the main problem is unknown exposure: Do you audit all old commits to find any sensitive data?
Shouldn't you audit all commits in any case?
The audit of commits in the general case (Checking for errors in the code) and the audit for the deployment case (Checking for sensitive data that may be exposed in a security breach) are different audits. I don't think many tend to do the second kind of audit.
Also, minimizing your exposure in case of a security issue is probably a good idea, so the convenience of deploying with git may or may not be worth this extra exposure.
Re: Let's deploy via Git
#110Here's one reason not to use git for deploy - if you don't want your source code on production servers where clients can access it, or where it could be found by hackers. I work on a closed source system, so we will never deploy our code via git and then build on the server. So, in this case build locally (or on a build server), and rsync from there using deploy scripts.
That's all well and true, but you could export and build, then use Git for deployment instead of Rsync (if you wanted to.)