Stop Manually Deploying WordPress Plugins and Use CircleCI Instead

I was working on a small security plugin a while back and decided to get it onto the official WordPress directory. But then I remembered the reality of the directory: it runs on Subversion (SVN). All my work, my entire workflow, is in Git. The thought of having to manage releases in two different version control systems was a total mess waiting to happen. I am not about to start manually copying files and running SVN commands from my terminal like it’s 2008.

This little headache is the perfect excuse to set up a real WordPress continuous deployment pipeline. It’s a problem that forces you to build a better, more professional workflow. Instead of just syncing Git to SVN with a bash script, you can build a system that automatically tests and deploys your code for you. Peace of mind. For real.

Automating Your Plugin Deployment with CircleCI

For this, I lean on CircleCI. Once you have it set up, the process is straightforward. You push a new version tag to your GitHub repository, and CircleCI takes over. It builds the plugin, runs all your tests (you *are* writing tests, right?), and if everything passes, it automatically commits the new version to the WordPress.org SVN repository. You don’t touch a thing.

My first thought was to find a simple script to handle the Git-to-SVN sync. And yeah, that would have worked, but it’s a band-aid. A real CI/CD pipeline does more than just move files around. It acts as a gatekeeper. By running unit and acceptance tests automatically, it ensures that a buggy release never even makes it to the directory. Trust me on this, it’s saved me from more than one embarrassing mistake.

The whole process is defined in a single YAML file in your repository, .circleci/config.yml. This file tells CircleCI exactly what to do. The setup can get pretty detailed, as Carl Alexander shows in his original deep-dive on the topic, but the core idea is a workflow with a few distinct jobs.

workflows:
  version: 2
  build_test_deploy:
    jobs:
      - build
      - code_quality:
          requires:
            - build
      - unit_tests:
          requires:
            - code_quality
      - acceptance_tests:
          requires:
            - unit_tests
      - deploy_plugin:
          filters:
            branches:
              only:
                - master
          requires:
            - acceptance_tests

Here’s the kicker: each of those jobs runs in a clean, isolated container. The build job installs your dependencies. The test jobs run your test suite against different PHP versions. And finally, the deploy_plugin job runs a script to handle the SVN commit, but only after everything else has passed. It’s a fan-in workflow where success at one stage unlocks the next.

So, What’s the Point?

Look, setting this up takes an afternoon. But it pays you back every single time you release an update. It’s not just about avoiding SVN commands; it’s about creating a professional release process you can trust. You can focus on building features and fixing bugs, and when you’re ready, you just tag a new release and know the rest is handled.

• Consistency: Every release is built and tested the exact same way.
• Safety: Automated tests prevent you from shipping broken code.
• Speed: What used to be a manual 15-minute process is now a hands-free background task.

Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.

Is building a full CI/CD pipeline for a simple plugin overkill? Maybe. But for a plugin you’re going to maintain for years, it’s the only sane way to do it. It’s the difference between a weekend hobby and a professional product.