WordPress has the ability to grow with your digital publishing requirements. It can be used anywhere from a small site that is hosted on the WordPress.com, to a self-hosted site on a pre-configured environment, all the way to a multi-site, continuous integration website, like re/code.
My use of WordPress has similarly grown. I started with a hosted site on WordPress.com to see what all the fuss was about, then moved to a multi-tenanted self-hosted domain, to my own AWS site. Mainly so I could learn about about analytics, HTML5, bootstrap, AWS – all while I was creating content.
Deploying code to a WordPress site isn’t for everyone… there are lots of pre-configured templates and hosting options out there. However, if you are developing WordPress templates, then automating the deployment process saves you a lot of hassle.
- It adds version control to your templates / projects
- You can stop using FTP to deploy your files
- Multiple people can be working on the same code base
- You can deploy to different environments. e.g. test, integration, DR, production.
- If you have a stateless WordPress architecture, then you can use the deployment process to auto-scale AWS.
I’ve setup a deployment process with Git, GitHub, Deploy and AWS EC2 although you could use other variants here such as BitBucket, BeanStalk, Jenkins, Rackspace, Digital Ocean, etc.
Nb: I haven’t figured out how to database deployments nor configuration files. That’s probably next.
What you need
Here is the basic architecture of what you need. You can use different variants of my configuration.
1. Local repository.
A local development environment to run WordPress plus edit the files.
2. Version control.
Even if you aren’t planning to automate the deployment of code to WordPress, having version control of your development environment is a very good idea. I’m using git. You can run this via the command line on a Mac but it’s almost simpler to run the GitHub Mac executable – which links to the next point.
3. Cloud code repository.
You need to push your version controlled changes to a cloud infrastructure, such as GitHub or BitBucket. I’ve used GitHub.
4. Deployment agent.
The final component is an agent to push changes from your cloud infrastructure to the different servers. This part can either be automated or manually triggered. I’ve used Deploy as it’s cloud based and free for my purposes but you can also use Jenkins or Beanstalk.
How you do it
My configuration is with MAMP, Git, GitHub, Deploy and AWS.
1. Setup your local development environment.
Funnily enough, when I was originally designing my first template theme, I was using a FTP client to download them off my AWS development server instance and then uploading them back onto the webserver. Pretty slow going…
It’s much easier to use a local development environment using MAMP or similar. This requires you to copy your code and your database into a local copy. However, it also means that you can download a dummy dataset into your database so you can test edge cases a little more easily.
2. Setup version control
I’m using github as a GUI version of git to maintain my git version control. So I’ve effectively combined this step and the next one. However, you can use git on it’s own to setup version control locally.
3. Initiate your cloud code repository
Setup either a bitbucket or a github account. Bitbucket allows you to have a few more private projects but I’m not really worried about my code being public so I’ve used github.
4. Commit your local version to the cloud code repository
When you create your github or bitbucket account, you can create a project from your local code instance. You will need to commit your changes and push to the cloud code repository.
4. Setup the deployment agent
There are a few options here. I’ve found the easiest to setup is deploy. However, if you have multiple projects then you will need to purchase a subscription. You could also use something like Beanstalk, or Elastic Beanstalk on AWS.
Create an account first and then create a project for deployment. You can link this directly to your github account to link the files.
You’ll need to give Deploy access via the SFTP key when connecting to an AWS EC2 instance. This is the most complicated element of this setup. You will need to copy the public key from DeployHQ into the .ssh/authorized_keys file.
You also need to give it the directory structure for your webserver. Normally this is under /var/www/html somewhere but different for each Apache installation.
You can then do a test to see that you Deploy can connect to both the GitHub repository and your deployment instance of WordPress.
You should do a first deployment to check that everything is working correctly.
5. Create deploy hooks to automate the deployments
Once you have tested that your deployment agent is working correctly with a manual deployment, you can then automate this process via a Deploy Hook. This gives you a URL to copy into GitHub for you to trigger a deployment.
You can test that this works by committing changes into GitHub and it should automatically deploy to your nominated WordPress server.