I'm currently developing my WordPress locally, committing my code to GitHub with Git and then SSHing into my server and doing a "git pull" to update my code. Is this a good option for code deployment onto a WordPress site (I obviously have root level access to my server in this case.) I know of things like Capistrano, but would that be overkill for deployment to a WordPress site? How can I make the most of Git/GitHub in this case?
I use git for this and find it works really well. A few suggestions:
I would highly recommend setting up Capistrano - it's a little bit of upfront work the first time, but after that you can easily use it for new setups.
The main advantages are
I'm adding a set of capistrano scripts to show you how I set things up.
and finally, a sample environment file (if you use the multistage gem, then you can have one of these for each stage of your environment, eg local, staging, production)
These files might not work without tweaking, and you'll need some basic Capistrano knowledge, but hopefully will help some people.
This was the first tutorial I used that got me going with Capistrano and WordPress: http://theme.fm/2011/08/tutorial-deploying-wordpress-with-capistrano-2082/
In short, I use GitHub to host the repo, and use a webhook to deploy changes based on the git ref. This allows you to use Vincent Driessen's git branching model and opens you up to having unlimited webheads, staging servers, testing servers, etc., all with automated deployment. I also cover keeping wp-config.php under version control while maintaining separate dev/production versions (by renaming the files and symlinking).
I know this question is a little older however as I've not seen this as answer here, I'd like to share what I normally do for single-site git based setups and deployments and it's working really well, also with working from multiple devices, locations and with multiple developers (all having their own local repos they operate in as it is common for git).
I can warm-heartedly suggest the following setup:
It is also outlined in (if you need a second resource to wrap your head around it):
It basically works (with at least three repos) by:
When the work is done you push against the remote bare repo you've cloned from. The bare repo has hooks to sync with the live repo (in the codes above called prime).
As Wordpress specific settings in the repo I have this
The rest incl. the plugin and theme configuration I keep under version/configuration control. This allows me to easily track changes and review code before using it live. I can also more easily merge against remote trees with my own changes. That is especially useful against the Wordpress core which is available on Github.
This works pretty well for most of my Wordpress needs. The bare repo prevents you from pushing conflicting changes. It also syncs to a remote copy first before updating the live-site. That means, updating the live-site is normally pretty fast. Because of the hooks you can even call Wordpress update hooks afterwards if you like.
If have not experimented how much this can be improved with Github hooks, but I normally do not need them as the code is under local version control, not Github.
To set such a system up for the first time, you should take some time to evaluate if you've got all the tools available on your remote host:
The setup-time for the first time should be possible within one two hours incl. the whole environment and you first publish push.
Depending on your host, you might also want to shield the
In short, everything not inside the public directory is not online. Inside the public directory can be the wordpress codebase for example, for the
This prevents direct access to public. Part of this .htaccess-foo you can find outlined here: Requests to .htaccess should return 404 instead of 403. For the environment variables you need to test if that works in your environment. Also you need to decide if you put that under version control or not.
If you have more control on the hosting, you can do more stuff here (and differently / more optimized), the examples above are targeted for typical shared-hosting environments (that offer GIT, some users say you can easily install it your own as well, I normally ask my hosters to provide such because I prefer if they take care that's what I pay them for).
On the negative side, this has some of the common problems also outlined in the other answers. One thing I'm not proud of but what works is to give the development host a change to it's host file to have the database server point to the development copy. So you can keep one database configuration. Not really cool esp. because of the credentials.
However I normally don't care much here but instead have daily backups run on the remote systems which are incrementally which themselves are stored in another remote location then. That's easy and cheap and allows you to restore both the Wordpress install as well as the file-uploads, the database and the git repo. Also for my backup commands I might not be perfectly alright, but those work for me:
What I do suggest here is that you keep the processes around your Wordpress installation out of Wordpress. They need to run on a specific system, so you normally do not have them inside the application (e.g. application can go down but you need to have these continue to work).
Enabled for Teamwork
Another nice benefit is that you site is enabled for team-work already. Thanks to the additional bare repo you can't do much wrong and you can even share remote branches apart from a master or live branch with your colleagues.