No time to write a full feature answer (I know sort of lame) but probably worth to share anyway (I might edit this because I plan a blog-post on this as well):
That means you can have some trunk/version-branch based WP setup that you can fully hack incl. themes and plugins.
As this is one independent (local) repository, you can push this via ssh to other repositories, for example one:
- That sits on the remote host where the site should be deployed at (bare repo).
- That has hooks to make another repository on that host actually merge in the changes you just pushed.
This is outlined in A web-focused Git workflow (Nov 2008; by Joe Maller).
If you then have a configuration switcher that chooses the concrete wp-config.php
based on the system it is running on, you can even centrally configure all hosts (development, live, staging, friends, ...) inside the repo.
Upstream changes in WP you do just fetch and merge in the subtree.
Plugins you just update and commit.
Deployment is a simple $ git push remote
.
Run daily backups on the remote host for the git repos, the database and the uploaded files and this is cheap, developer friendly and flexible. This works well for single-developer setups as well as for small teams because everybody can checkout from the bare repro on the remote.
There are some caveats:
Now with your checklist and the setup as outlined above:
1. Would like to have my git environment on my own server internally, not using Github to handle repos.
Github only handles upstream repos here (Wordpress), not your own one.
2. Automatic creation of subdomains upon git branch creation (development.domain.com , ryan.development.domain.com) - Probably some shell script hook would be ideal for this.
The setup as outlined is a modular approach with one repo per site. It can handle as many development hosts as you like, it might equally work well with a multi-site install to handle multiple domains, but that would count as one wordpress setup in this approach.
3. Phing PHP/Shell script Handling of the db migration (something like this http://interconnectit.com/products/search-and-replace-for-wordpress-databases/ ) to handle serialized database replacement upon pushing
This is not needed here as only the code is under version control, the databases are independent between development (, staging) and production as it should be.
You might be looking for an install script that does the domain migration right, but even with better code (that is available) dealing with serialized data search and replace, in this setup here it is normally not necessary as you just push the changes to live, for the test-cases you can quickly create the content in the development database, that is normally the smallest problem (from my practical experience, yours might differ, but I would also suggest to keep such database-migration related topics on questions of it's own here on site - but please ask them).
I run about 200 sites on my own server and would like to start implementing these sites into a strong git workflow environment so i can streamline my work a lot better.
I can not imagine how those sites would become under a string git workflow environment. Perhaps the configuration scripts and configuration data you manage here will be kept under git version control. That could make sense. Otherwise by the sheer amount of sites I think it makes no sense at all to keep all those in one git repo. Perhaps not even one of those because what I outlined above is for sites you develop (incl. the WP core code), not just for installation tasks. So you probably need to first of all create yourself some little map of those 200 sites and how they interact with each other and out of which packages (WP core, Plugins, Themes) those sites consist. First thing could be creating a spreadsheet / matrix and put all sites in.
You can then save it as CSV, put it under version control and make the deployment scripts do their work based on that file.
And if I've learned something with automating tasks: Follow the Unix philosophy, use the existing and well working tools (it's better to spend half a day reading about some commands then trying to search for alternatives because for most jobs, the problems have been solved already) and focus on command-line tools. They are most powerful.