Here is a small new service, that should make life a little bit easier for my fellow WordPress plugin developers. I’ve first presented it at WordCamp Lithuania last weekend and since then, more than 10 plugin developers have signed up.
So, without further ado, please meet Deployer. As it says in the front page, Deployer is a service, that automatically syncs Your plugin code from GitHub to WordPress.org plugin directory.
The Problem
Traditionally, if you wanted to publish a plugin to WordPress.org directory, you needed to know how to use Subversion(SVN). For you youngsters out there – Subversion is a version control system that was cool before Git came along. And because it was cool in 2003, when WordPress was being created, SVN became the basis of all infrastructure for WordPress project. Core, plugins, themes – everything is versioned using SVN.
Like any other version control system, SVN has its own pros and cons. The main disadvantage that SVN suffers from nowadays is not being Git. All the young developers know how to use Git, all the old ones do, too. Github is an awesome place to host and develop opensource projects, because it has nice tools for issue tracking, merging, pull requests, etc.
Also, it is easy to contribute via GitHub, especially if compared to SVN and WordPress plugin directory. In all the time that I’ve been developing WordPress plugins, I’ve not received a single patch for my plugins via SVN/WordPress.org. But I have received numerous pull requests via GitHub and, as I am now finding out, GitHub is also really awesome if you are working in a team.
Because of all that, a lot of new WordPress plugin development is happening on GitHub, and only new releases are published via SVN. It can be done, but the process is cumbersome and, if you have quite a few active plugins, can become quite tedious. You have to clone your git repository, checkout your SVN repository, put the new version in correct place, refresh the readme.txt file and then commit everything to SVN repository. Rinse and repeat with every new release.
Previous solutions
Developers have been trying to automate this process for quite a while. There are Grunt scripts, Bash scripts and other kinds of tutorials of how to make this process more straight forward.
A few months ago, Ship was introduced. It was a service that fully automated the process of publishing new versions to WordPress.org via SVN and allowed developers to do all their development on GitHub. Having 10 plugins to maintain, I was really excited. But there were a couple of drawbacks.
First, Ship required pretty wide access to my GitHub account. GitHub does not provide granular API access, so I’d have to grant Ship access to all my GitHub repos, not only the one I wanted to publish from. That includes my private repos.
Second, Ship needed my WordPress.org credentials. And because it will need to use them regularly, they could not really hash them and had to store them in plaintext. Again, that would give Ship access to everyhing in my WordPress.org account. All plugins, all themes, all comments, all translations, etc. Everything.
Naturally, a lot of developers did not trust the service enough to grant that much access. So it got me thinking. And Deployer was born.
Deployer
In a sense, Deployer is pretty similar to Ship. It also tries to automate the whole process of publishing from GitHub to WordPress.org SVN repository. But it takes quite oposite stance when it comes to requiring access. Where Ship requests a lot of privileges, Deployer asks for almost none.
GitHub. Deployer asks no privileges on GitHub. Public GitHub repositories can be cloned without any limitations by anyone, so Deployer does that. Deployer would need access to set up a WebHook for itself, but instead of requesting access Deployer provides step by step instructions for user how to set up the Webhook manually.
WordPress.org. Instead of requiring user’s WordPress.org credentials, Deployer has a dedicated WordPRess.org user, deployer. User has to manually add the deployer user to his plugin’s committer list, thus allowing that user to commit code to plugin’s SVN repository. This also enhances security, because WordPress.org can identify all the commits, made by deployer user and roll them back in case there is a breach from Deployer’s side.
Because of this tactic, Deployer can keep a very light touch when it comes to privileges. But that also means, that there is no ‘single button’ installation, and user has to complete several manual steps to properly setup Deployer. Also, Deployer currently does not work with completely new plugins, because WordPress.org does not allow to add new commiters, until at least one commit is made by original author via SVN.
Usage
Deployer currently handles three scenarios:
- Releasing a new version
- Updating
readme.txtfile - Updating plugin assets
Releasing a new version
To release a new version, you need to git tag a new version in master branch of your GitHub repository:
git add readme.txt
git add plugin-file.php
git commit -m "version 1.0.1"
git tag 1.0.1
git push origin master --tags
Updating readme.txt file
readme.txt is a very important file for a WordPress plugin. WordPress.org plugin directory picks most of the displayed content out of this file, so plugin authors might need to update it quite often.
To update readme.txt just update it in master branch of GitHub repository
git add readme.txt
git commit -m "readme update"
git push origin master
Updating plugin assets
Plugins store some graphic assets, that are being used in WordPress plugin directory in a special folder in their SVN repository, called assets. To let Deployer handle plugin assets, you should create an empty branch assets in your GitHub repository and put all asset files there.
Deployer updates assets on WordPress.org with every commit to assets branch in your GitHub repository.
git checkout assets
git add -A
git commit -m "new banner and updated screenshot"
git push origin assets
And that is pretty much all. You work on your GitHub repository and WordPress.org gets updated automatically whenever you trigger related actions. Try it out at deployer.edwinapp.com. And let me know if you run into any issues!
Don’t forget to share this via Facebook, Twitter, Google+, LinkedIn and Reddit.