How I use Continuous Integration in WP Development

This post was originally published on my blog at wpmastery.xyz/continuous-integration-for-wordpress-developers/.

Writing high-quality and stable code for WordPress is tough. The Core is written in a procedural style and keeping data in sync between local, staging, and production environments can be a nightmare. Staying on top of the changes in new releases, implementing best-practices while writing code, and ensuring your code plays nicely with 3rd-party plugins requires our full attention.

But if your WP agency wants to deliver websites, plugins or themes that run stable and perform well, you need to write maintainable, performant and secure code. Continuous Integration can play a huge role in the process of developing WordPress sites and WordPress products. In this post, I want to share with you how and why I added Continuous Integration into my WordPress development workflows.

Let's first take a step back and see what Continuous Integration is. Microsoft defines CI as:

Continuous Integration (CI) is the process of automating the build and testing of code every time a team member commits changes to version control. CI encourages developers to share their code and unit tests by merging their changes into a shared version control repository after every small task completion.

Sam Guckenheimer - https://docs.microsoft.com/en-us/azure/devops/learn/what-is-continuous-integration

In the WordPress world, it means that your theme code or plugin code will be thoroughly managed in version control systems and thus can be analyzed & tested automatically. Upon each commit to your repository - no matter if that's GitHub, Bitbucket or something else - you can execute a series of tasks that monitor and ensure your code quality.

As you might have experienced yourself, working on WordPress projects doesn't always work in this beautifully structured way. Sometimes we have to deploy hot-fixes on live websites, change code via SFTP directly on a server, or do not even bother to set up version control because the project is so seemingly small.

I have been guilty of doing all of this. And I paid the price more than once. Projects got out of hand, bugs that were once fixed got re-introduced by accidentally overwriting a hot-fix, and I lost track of what bugs were still open. You've probably seen projects go very messy very quickly, too.

That's why I set out to find a solution for these situations. I wanted to bring predictability and stability to my projects. Continuous Integration came to the rescue!

For example, I read that WordPress developers can use Continuous Integration to run PHPUnit tests, automatically deploy code onto your staging or live server, or use static code analysis tools like PHPloc to make your builds & deployments fail if your code gets too messy. That sounded like exactly what I needed, so I implemented CI in my development workflows.

Getting Started with Continuous Integration for WordPress Development

Implementing Continuous Integration does not require a lot of money. In fact, I run my own CI pipelines based on a $5/mo Digital Ocean droplet and open-source software. However, it took me many hours to refine the process. Be prepared to spend some time if you're implementing CI on your own.

Let me walk you through the step-by-step process I took to automate my deployments to my Cloudways servers. That should give you a rough idea of how you can leverage Continuous Integration in your own WordPress development processes.

Firstly, I set up a Ubuntu droplet on Digital Ocean for $5 per month. I did not want to spend huge amounts on my CI pipeline and wanted to avoid being limited by 3rd-party tools - so hosting my own server felt like the way to go. It turned out to be much less effort in maintenance than I expected. I do have a referral link to Digital Ocean that gives you $50 in credit.

Secondly, I installed the Continuous Integration software Jenkins on the Ubuntu droplet. I see Jenkins as a virtual butler that handles automation for me. I connected Jenkins to my GitHub repositories so that it has access to the project files I'm working on at any time.

Thirdly, each project (e.g. plugin or theme) needed to have the tool PHPloy installed. PHPloy can be used to deploy code via SFTP/FTP and was the perfect choice to run automated deployments independently from your target server. Though Cloudways offers automated deployment via GitHub, I found that to be limiting. I could just connect one repository per application, so it wouldn't work for a plugin and a theme on the same application if those reside in two repositories.

Fourth, I set up simple automation pipelines in Jenkins using Jenkinsfiles. Those are scripts written in Groovy (I have no knowledge of Groovy whatsoever) that tell Jenkins what to do when you commit code to your repositories. In my case, they trigger PHPloy and perform static code analysis. Soon, they'll also trigger unit testing and code optimization.

That's all it took for me to automate my deployments when working on code. I am not touching FileZilla or other SFTP clients anymore to upload code to a staging or live server. It's all fully automated and I'm loving every bit of it. Honestly, setting up this CI pipeline was quite a strain. There were moments I felt like giving up and throwing my MacBook against the wall or my Win10 desktop out of the window. But in the end, the work pays off.

Issues I Solved With Continuous Integration

I wanted to add CI to my WordPress development workflows to get rid of multiple issues. Those were things I faced on a daily basis and that led to me wasting time in my projects. And time is the last thing we developers can afford to waste.

1. Easier collaboration in teams. I'm in multiple projects that involve another agency. Knowing that we all are forced to work in the same repository streamlines communication and increases transparency in what's happening on the staging and live server.
2. No more accidentally overwritten files. Especially in the projects mentioned above, it would happen that file transfers via SFTP would accidentally overwrite files that had been changed on the server instead of in the repository. Somebody would deploy a hot-fix on the live server, which would then get nuked by the next code deployment - bringing the error back to the live website.
3. No more manual file transfers. I admit it, I'm lazy. Having to always transfer my code manually using FileZilla annoyed me.

If you're still reading the article, I want to thank you for following my thoughts on implementing Continuous Integration for WordPress development. Maybe you're now also seeing the potential it can bring into your organization. And even as a single freelancer, you can save quite some time with CI and its automation capabilities.