WordPress plugin development is succinct and powerful. Other than the plugin descriptor and a README, you can jump right into writing problem solving code.
Useful plugins with only one line of (non-comment) code exist and are in circulation, like Disable XML-RPC which has hundreds of thousands of downloads.
So it’s all fantastic, but if you want those downloads you’ll probably need to get your code into the WordPress plugin repository, and there’s a speed bump there:
WordPress forces us to use SVN and a specific directory structure to deploy to their repository.
As a Git user, I hate the idea of having to commit and push, then pull or copy the files into another couple of directories (yep, duplication…), and commit and push again, every time I want to deploy an update. I’ll also have to figure out SVN commands that I’m not familiar with and clone two repositories to get to work in a new environment. Redundancy sucks.
Enter Codeship: a plug ‘n’ play testing and deployment solution which doesn’t impose any changes to your environment or deployment process.
The only assumption is that you’re using Git (they may support other VCSs, you should check).
Pushing to master (or a branch of your choice) is deploying to the WordPress plugin repository.
Brilliantly elegant, automagic WordPress plugin deployment.
Codeship has preset deployment configurations so you can just fill in the blanks (i.e. for Heroku), but the WordPress plugin repository is not one of them. That being said, I had little trouble using their custom script functionality to get the job done, and that’s what this guide will take you through.
Edit: this guide has undergone a breaking change on 2015/08/30. If you worked through it around this time or up to a month earlier, consider going through it again to ensure smooth operation. It particularly regards the assumed directory structure, and involves a change in the deployment script.