WordPress Git Workflow Help

2 comments

1. General Questions answered

   Nr.1. Would like to have my git environment on my own server internally, not using Github to handle repos.

   The first thing I’d do is to check out composer and how it works with WordPress, which is a project by Andrey “@Rarst” Savchenko.

   Nr.2. Automatic creation of subdomains upon git branch creation (development.example.com, ryan.development.example.com) – Probably some shell script hook would be ideal for this.

   This is something out of scope for this site. Either ask for help on StackOverflow or ask at your hoster. Some hosters don’t allow to edit these entries yourself.

   I’d set up a multisite/network install. This allows to easily manage all the tables, keep the users in a central place, etc.

   WP Gear – a project by Robert “@Wyck” Ellison – has a list of alternate build scripts. Including WordPhing written by himself. @TomJNowells/Interconnect.it script so far isn’t in that list.

   Operation Questions answered

   Nr. 1. getting the current latest wordpress version and branch it out, name of the branch gets a subdomain entry (branchdevelopment.domain.com)

   Not sure why one wants to do this: A subdomain for each branch. When you look at the synced WordPress GitHub repository and the list of branches, then you’ll see that every branch is named X.Y-branch. So your subdomains would get named for e.g. 3.6-branch. I’m not sure if a subdomain is allowed to start with a digit (it should be, but ask your hoster) and then there’s the problem that you’d get a sub-subdomain named 6-branch, which has a sub-sub-subdomain named 3 and another one named 2. And guess pairing 2- and 3-version branches in a subdomain isn’t what you want to achieve.

   In short: Just checkout 3.6-branch if you need to switch branches.

   Nr.2. submodule the theme you desire if it’s available (i’d like to make my own git repo for this, as I use thesis I’d like to have a blank thesis git repo setup to grab from internally on the server that’s already been created)

   Thomas “@toscho” Scholz has written a nice plugin that allows us to use a subdomain to handle themes outside the WordPress directory. You can find it in this answer as well as in this one. Even automatic updates will work for themes since WP 3.6.

   You can do the same for MU-Plugins and Plugins by simply setting the following constants in your wp-config.php file:

   define( 'WP_PLUGIN_DIR',   'path/to/your/plugins.dev/folder/plugins' );
   define( 'WP_PLUGIN_URL',   'https://plugins.dev/plugins' );
   define( 'WPMU_PLUGIN_DIR', 'path/to/your/plugins.dev/folder/mu-plugins' );
   define( 'WPMU_PLUGIN_URL', 'https://plugins.dev/mu-plugins' );
   

   Now simply put all your plugins and themes under version control and push them onto your server. You can easily make them all available using either mu-plugins or default plugins that get network activated.

   Nr.3 checkout and make changes, client reviews, once it’s pushed to live, the database script will then kick in automatically changing the serialized url values from localhost (or subdomain) to the live url

   If Toms script/plugin doesn’t help you so far, then be told that he accepts pull request on GitHub.

2. 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):

   • I’m cloning WordPress from Github (you can even do this for the source tree from here: tierra/wordpress)

   • I then use it as via a subtree merge in my own sites repo (I even run over a bug in git but it’s solution is here: -X subtree=…).

   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:

   • The git aliases git accept-theirs and git accept-theirs are helpful in case there are conflicting baseline changes you clearly know which one you prefer to deal with. You find that here: Simple tool to ‘accept theirs’ or ‘accept mine’ on a whole file using git
   • Hello Dolly. The Curse of an entire generation. You need to rm it always.

   ---

   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.

Comments are closed.