There has been a lot of talk about using version control to deploy WordPress lately and not a lot of usable material about how to actually accomplish this. I thought it would be good to cover this in an article, however; I soon discovered that no single article could truly encompass the subject thoroughly so this will be a multipart series. And since this is likely to be a long article let’s just jump right in.
On GitHub create a new repository.
In your file system run: git clone git@github.com:mikelking/konexus.git to create the project stub. Download and unpack the current version of WordPress into the root:
curl -o http://wordpress.org/latest.tar.gz tar xzf latest.tar.gz
At this point you will have a structure similar to the following:
This is important because it keeps the .git, license and readme out of the WordPress root which just makes things cleaner. A quick look at the git status will display:
We need to add wordpress to the repository with git add wordpress followed by a commit like this:
git commit -am ‘Initial import of WordPress 3.9 core.’
Finally we do a git push and you will see something similar to:
After Examining the github repo page you can confirm that we have pushed the WordPress core out.
In dploy.io connect the system to github and select a repository.
Once connected you will be informed that the the new repo is being initialized and that you are out of repositories. You do not need to wait until the repo is fully initialized on dploy.io simple return to the dashboard and begin configuring your deployment environment. The first step is giving the environment a name like Staging or Production. This is required… If you have HipChat you can configure it here or you can always return later to add that to the environment.
After defining the basic environment you need to decide the server type you wish to add. I am going to go out on a limb here and tell you to NEVER, EVER, NO NOT FRAKKIN EVER select FTP. Jut pretend that that option does not exist and skip down to SFTP. If you are familiar with ssh then password-less sftp will make the most sense to you.
The following screen shot gives you some idea of what you need. Notice that I have check the ‘Use public key for authentication’ box. If you go this route then you must download the public key and insert it into the authorized_keys file for the deployment user. Also keep in mind that you may need to add some exclusions to your firewall rules: http://support.dploy.io/customer/portal/articles/1292499-ips-and-ports-for-firewall-setup for port 22 for the IP address block 50.31.156.48 – 50.31.156.79
Once you’ve setup everything check the connection. If all goes well you will end up on the final server setting page where you can define pre & post webhooks or even fire off shell scripts. I use this to trigger a marker in my NewRelic graphs.
see for more info: http://support.dploy.io/customer/portal/articles/1302306-how-do-i-trigger-pre–and-post-deployment-web-hooks-
Remember that you can always modify the server settings at a later time. Assuming that you have successfully configured the server then you will be able to select the deploy button. In this screen I have setup the deploy to the production environment we just configured.
Once you click the ‘Start Deployment‘ button you will be able to see the magick happen on the status page. A typical issue that may cause a deploy failure especially the first deploy is forgetting to set the correct ownership and permissions on the deploy root.
-rw-r--r-- 1 dployio dployio 41 Apr 24 15:22 .revision -rw-r--r-- 1 dployio dployio 1485 Apr 24 15:20 LICENSE -rw-r--r-- 1 dployio dployio 16 Apr 24 15:20 README.md drwxr-xr-x 2 sysmgr sysmgr 512 Jun 10 2013 logs drwxr-xr-x 5 www www 1024 Apr 15 16:35 public -rw-r--r-- 1 dployio dployio 3283 Apr 24 15:22 server-config.php drwxr-xr-x 5 dployio dployio 1024 Apr 24 15:22 wordpress
Some things to note, the file ownership of the deployed files are all dployio because that is the user we specified in the server configuration. Also the existing files and directories in the destination were ignored, which is handy considering the actual current site if being served out of public and not the wordpress directory. This also keeps the site specific logs intact. Also notice that dploy.io included a .revision file which coincidentally contains the git hash of the currently deployed revision. At this point all that I need to do is configure my database and new WordPress installation. Then adjust my vhost config in apache to serve from the new location and gently restart Apache.
Some final notes worth exploring. If you add multiple servers to a particular environment and one of those servers fail to deploy the whole will be marked as failed. This is particularly troubling when you have a dynamically expanding environment say on some sort of cloud based server instance system where the load (or lack there of) may cycle down a server. At this point there is no way to place a particular server in ‘Maintenance Mode’ which would be helpful.
Honestly it is nearly impossible to have identica staging and production let alone development environments so in the next article we will definitely expand on this by demonstrating how to create an adaptive configuration for each WordPress environment. In addition we will cover how to adjust the new auto updates feature to work with our deployment solution.
Another issue is if your work flow requires a deploy to an intermediary environment like a staging or princess level before a deployment to production can occur. You need to understand that dploy.io does not currently support deployment chaining. While I do have a couple of ideas on how to achieve this I will also save that for another time.
I hope you have enjoyed this streamlined over view and tutorial about deploying WordPress via git. This is just the beginning so please join the discussion below and share your thoughts.
Related articles
Leave a Reply