A pair of scripts that make it easier to manage the development of a WordPress plugin in Github, and then periodically deploy to the WP.org plugin repo (SVN).
Developers seem to love to hear about how other developers work, so I thought I’d try to capture my entire environment, from end to end, in a single post. This will change (has changed) over time and depending on the project/company/whatever, but this is how things are for me right now. A couple of points up front:
- I work for Automattic, so a lot of this is influenced by our internal policies/security/workflow.
- I don’t always use all components of this “system”. I’ll try to detail when I do/don’t use certain parts of it as I go.
OK, here goes.
Note: This turned into a little bit of a summary of how we work internally at Automattic as well. Oh well, maybe it’ll provide some inspiration, I think we do some pretty cool things.
For a number of reasons at a number of times in my career, I’ve found myself working with variously-distributed teams of one kind or another. Perhaps the “office” is a building that spans 2 square miles, perhaps someone was working from home for a day or someone was on a 2 week “vacation”, or even working for a distributed company with no real office. These were all different situations, but they all suffered from simliar challenges. I want to take a look at a couple of those challenges and some ways that you can help mitigate them.
I’m looking at this mostly as a member of a technical team of some sort, but I’m sure a lot of it would apply to pretty much anyone who’s not working face-to-face with their colleagues. Apologies in advance for this being kind of rambling (and very long). It’s a collection of all sorts of observations, links and ideas that I’ve collected over time. (more…)
There are a number of different ways to manage a WordPress installation, everything from not actually managing it yourself (WordPress.com can take care of it for you if you like) through to manually managing things via FTP. I’m going to look at my preferred method, which I think provides a few things that other methods don’t necessarily give you.
- Control: this method puts you in charge (which also means it’s your responsibility to keep things up to date).
- Safety: if you consistently manage your WordPress install using this method, then you’re in a pretty good position to avoid a lot of problems.
- Simplicity: WordPress updates quite often (minor releases at least every month generally). This system means that you can generally update when a new version comes out in a few minutes at the absolute most.
What is this magic system you ask? In a word: Subversion.