My Software Development Workflow: Tools, Tips, and Habits

I recently joined Carrie Dils for an Office Hours discussion about workflows. Here’s a concise summary of what we covered.

Themes

I maintain two starter themes: EA Starter, a heavily modified underscores-based starter, and EA Genesis Child, a Genesis child theme. Both share a similar structure. EA Starter integrates hooks from the Theme Hook Alliance to make development more Genesis-like. Roughly half of my projects use Genesis while the other half are custom WordPress themes.

Across all projects I rely on a Core Functionality plugin to centralize site-wide features, and I keep a simple mu-plugin in my local environment to provide quick links in the admin bar.

Build Tools

For local front-end workflow I prefer CodeKit for SASS compilation, JavaScript concatenation and minification, and live reloading. CodeKit is especially convenient for solo development; in team environments it’s important to align on a shared build process, in which case more cross-platform tools may be preferable.

I’ve been expanding my toolset with gulp while developing the Shared Counts plugin in collaboration with Jared Atchison. I’m also learning webpack and Babel as part of Gutenberg block development described in my post on building Gutenberg blocks.

Deployment Tools

I use WPEngine as my primary development host, and I document the Git-based workflow in my post about Git Push with WPEngine.

For synchronizing databases and media between environments I use WP Migrate DB Pro. To automate push and pull operations I trigger WP Migrate DB Pro from a bash script. Running a command like project.sh push performs a sequence of steps:

1. Pushes code to GitHub.
2. Pushes code to the appropriate WPEngine remote branch (production or staging), based on the BE_PUSH_TO value in wp-config.php.
3. Pushes the database and media using WP Migrate DB Pro (via the CLI command for a specific profile).

Because the WP Migrate DB Pro CLI accepts only profile IDs, I create the migration profiles in a predictable order. My initial setup process is straightforward:

1. Create a local WordPress environment (for example, clientname.local).
2. Create a transferable install on WPEngine (for example, clientname.wpengine.com).
3. Install and configure WP Migrate DB Pro on both environments, enabling both push and pull.
4. On the local site, go to Tools → Migrate DB Pro, choose “Push”, enter the remote connection information, check “Media Files”, and save the profile (I name it “WPE Push”).
5. Create a second profile for “Pull” with the same settings and save it (I name it “WPE Pull”).

Editing Production Sites

When a client is hosted on WPEngine, I generally use Git to deploy code to staging and production environments; see my guide on Git Push with WPEngine for details.

For clients hosted on other platforms, I typically use WP Pusher to deploy plugin and theme updates directly to the production site without manual FTP.

Larger Sites

Large sites introduce challenges around media synchronization. To avoid copying massive media libraries, I often install BE Media from Production. That plugin rewrites media URLs so the local environment references media on the production host, allowing themes and plugins to be present locally while images and other media still display correctly.

I add the plugin as an mu-plugin and include a small local mu-plugin (for example, a local-settings.php file) where I specify the production URL. This keeps local development lightweight while preserving the visual integrity of the site. For a step-by-step walkthrough, see my post on Load Media from Production.