Yes, you read that title correctly. Why on Earth would anyone deploy WordPress through Team Foundation Server (TFS)? It's simple: if you want a streamlined DevOps solution to continuous integration (CI) and continuous deployment, you really can't go wrong with TFS.

I currently work for the School of Medicine at the University of Virginia (UVA), and our software development and integration division has invested in TFS as our project management and source control solution, but it's much, much more. TFS allows for building, deploying, and testing of software solutions through automated build steps, helping to eliminate the human error.

Recently, our school completed a Plone-to-WordPress migration, and as a part of it, our team was brought in not just for server management, but various DevOps tasks, as well as custom debugging of Shibboleth authentication. One of the must have line items of the migration was an enterprise level source control and build solution.

Source Control in TFS is a simple matter. You just navigate to the 'Code' tab, click on the repository dropdown, and click on the link to manage repositions. From this screen, you can create TSVC or Git repositories. WordPress itself is hosted on GitHub, and our WordPress sites are hosted on Linux servers, so Git was the obvious choice.

Just throwing code in a Git repo is one thing, but the School of Medicine network consists of over 100 sites and sub-sites; there are over 80 active plugins and several themes. Making that a single repository is overkill, so we broke out the plugins, the mu-plugins, the themes, our DevOps script, etc., but when you do this, there is always the question of maintenance. How do you instruct a developer to set up and organize such a structure locally? How do you set up your deployment scripts to correctly merge back together your repositories?

Git itself has a submodule ability that addresses this. You can point one Git repo to another Git repo, and essentially tell Git to check them all out together in the right structure. It's similar in concept to linked folders or symlinks.

On the deployment end, TFS allows for submodule usage, and you have the option to check those out during a build process. This solves merging things together for the deployment as well.

Since WordPress is written in PHP, the build solution doesn't need to compile the code, but deploying the code to integration, staging, and production environments requires appropriate deployment steps. TFS offers cURL as a potential build step, and this was our first option. It's simple, easily maintained, and most will be familiar with it. Unfortunately, cURL has an argument length limit that TFS will choke on. The error it returns claims that a filepath is too long, but trust me, it's from the argument length. After all, WordPress has a lot of files to transfer if you ship the entire site.

This meant that we needed another option, and when in doubt, write a PowerShell script. Since our server was only accessible for file transfers via SCP or SFTP protocols, we installed the pscp.exe program from puTTY, and then wrote a simple PowerShell script to start up that process:

The TFS build step for PowerShell allows you to pass in parameters. In this script, it expects ordinal parameters (separated by spaces; use quotes if your parameters naturally have spaces within them), and simply passes those parameters to the pscp.exe process. Notice the -Wait argument being passed to Start-Process. Without this argument, the TFS build process will assume that the build step is over once the PowerShell script is finished running. The problem is that pscp.exe is running in a different process, and will be cut off, failing to finish. Make sure you have that -Wait in there.

With this simply script, you can now deploy and entire WordPress site through a TFS build step.