I started with sftp, then switched to WebDAV and I’m currently using rsync through ssh to deploy any updates/upgrades from my development server into my production server.
I’m still not very happy using this system and think using git to deploy may be better, mainly because of the possibility of rolling back any changes instantly with just one command.
Appart from using ssh tunnel to pull and push to the production server (leaving the git service behind the firewall), I’ve also realized I have to edit .htaccess to deny web access to .git folder.
Is this the correct approach, should I check anything else, do something in a different way, or should I go in a totally different direction?
That depends on your exact way of doing it. Right now it seems to me you have a git repo in your httpdocs that you deploy to, basically using HEAD as your actual website – that is NOT the correct way. I’m not sure how you are able to push to this configuration at all?
What you want to do is use a bare repo somewhere outside the httpdocs-folder, and checkout the files to httpdocs after pushing. While this sounds complicated, its pretty easy to do, here is a step-by-step tutorial: http://caiustheory.com/automatically-deploying-website-from-remote-git-repository
If your webserver needs access to some files, such as a wordpress installation, you need to add chmod and chgrp commands to the post-receive hook, otherwise your files belong to the wrong user (the one you used to push the commit, not the webserver).
Simply make a new script to change ownership that you call from the post_receive hook via sudo scriptname.sh (name it change_own.sh or whatever) :
chown -R wwwrun /path/to/httpdocs
chgrp -R www /path/to/httpdocs
and allow the script to be run without password via visudo by adding gituser ALL=(ALL) NOPASSWD: /path/to/change_owner.sh at the end.
Assumptions made: wwwrun – webserver user; www – webserver group; gituser – user to push commits
Addendum: A friend used this method and complained about how he had to update WordPress over and over again. The obvious reason is that if the Webapplication updates itself, und thus replaces its code, these changes will not be transferred back into the repository, because the hook only works one way. Thus after each commit, the hook overrode all changes the WordPress-Installation made through updates. The imho quickest workaround is to run the updates on the developer machine, then commit to deploy.
I think using git to manage the set of files needed to run your site is a clever idea.. as a matter of fact there are several services already doing this (as far as I know): microsoft’s azure and some node.js hosting sites like nodester.com, just to name a couple..
As also @phi said, I’d not place the repository on the very same folders you publish through the web server, but have instead some kind of procedure which lets you “get the files” from the git repository and place where your web server will use them.
Just be sure to think all the details.. for instance:
- if you have user-generated files, when you rollback or otherwise re-publish your site are they to be overwritten or kept in place?
- if you have database data, when you republish your site will everything match and be ok, or should you handle the possible mismatch in some way?
There might be other culprits to think about, but the general idea is nice =)
4