the words "How I Hope to Stop Repeating Myself" on a background of repeated shadows and building architecture.

Open Sourcing My Task Checklist for a Freemium Plugin update.

ByBen Meredith

Over the weekend I updated Better Click To Tweet to a new version, and both premium add-ons got that glossy coat of paint to match.

Since the beginning, it’s always been my training ground as I’ve learned to support a product, sell a premium product, learned to product manage a product (I outsourced much of the development to a fantastic agency for this round), and release an update to a product.

In addition to the updates to the actual product this time around, I also spent some significant time offloading the process so that I don’t have to remember each time I do an update all that goes into doing that update. Here’s what my process used to look like (until this weekend):

  1. Make some cool code changes to the plugin, and thoroughly test them on one development site.
  2. Try to approximate what the actual update process will look like for my users and customers. This involved a ton of guesswork to make ZIP files that may or may not actually be the one that WordPress dot org delivers (in the case of my free plugin) or betterclicktotweet.com delivers (in the case of the premium add-ons).
  3. Google the exact syntax of the WP CLI command for creating the POT file.
  4. Make a few more changes based on my tests.
  5. Google that same syntax from step 3 again because 2 of the changes in step 4 changed line numbers in the POT file.
  6. Forget whether it’s npm run dev or npm run build or npm run production that I am supposed to run for a live build. Search my own codebase for answers.
  7. Search Twitter DM history with developers who are smarter than I am, because I know I asked them at one point.
  8. Run npm run build manually on the local repo.
  9. Forget with exact files I am supposed to remove from the ZIP (or SVN repo) that ships with the add-on (or core product on SVN)
  10. Search the same DM history, and copy-paste the correct steps into a local terminal.
  11. Release the goods. (I’ll spare you the “relearn how SVN is different from GIT” steps for the dot org plugin)

As you can tell, there’s MUCH to be improved upon in my workflow. And because I only do it every few months, I essentially have to relearn all the steps each time. Invariably I miss some steps each time and cost myself too many hours.

A few releases ago I created a bash script for add-ons and another for the core (dot org) releases, and that worked fairly well.

My workflow worked fairly great for a live release. The problem is that I prefer not to make lots of mistakes on a live release. I’d rather correctly deliver the SAME files I would have on a live release, then test them, and then run an ACTUAL live release.

I need a “dry run” mode.

I’m so happy to announce that this weekend I leveled up my bash scripting skills and added in a method to do all of the same ZIPping, cleaning, and releasing that happens in a live release while only creating a local ZIP that I can then use for testing.

Even better than that, I added prompts in the script that remind me of how to release. The WP-CLI command for adding a POT file? It’s now copy-pastable for me! The npm command? It happens automatically!

The best part is that it’s the same script running for test and live releases. The difference is that I have to explicitly tell the script to do it LIVE. Otherwise, it’ll just do everything that happens on a live release with one glorious exception: It won’t actually release anything for customers to be confused by, and I won’t have to release and then HUSTLE to release a patch 25 minutes later!

You can see the exact script I use, which has been modified by several other folks (credited in the code) and is free for you to fork and use here: https://github.com/Benunc/plugin-release-shells/tree/bctt-plugins

The most recently updated two are the ones you’ll want to emulate. I’m happy to answer questions about them as well. Hit me on Twitter @thewpsteward

Similar Posts