Software Development Workflow Guide: Tools and Process

I recently joined Carrie Dils for an Office Hours conversation about workflows for WordPress development. Below is a clear, practical summary of the tools, patterns, and deployment steps I discussed, organized so you can adapt the ideas to your own projects.

Themes and Project Structure

I maintain two starter themes to accelerate new projects and enforce consistent structure. EA Starter is a heavily modified underscores-based starter, while EA Genesis Child is a Genesis child theme. Both follow the same organizational approach so switching between Genesis-based and custom themes is straightforward.

To make custom themes feel more like Genesis in terms of hook architecture, EA Starter uses the Theme Hook Alliance. For most projects I pair a starter theme with a Core Functionality plugin that contains site-wide behavior—this keeps theme code focused on presentation. On local environments I also use a small mu-plugin for admin conveniences like quick links in the admin bar.

Build Tools

For compiling SASS, concatenating and minifying JavaScript, and live-reloading during development I use CodeKit. It’s a simple, efficient solution for solo development where syncing build environments with collaborators is not required.

When collaboration is necessary or when I need a more reproducible build setup, I use gulp. I began applying gulp in projects such as the Shared Counts plugin, where a consistent build process across multiple contributors matters. For modern JavaScript and block development I’ve been experimenting with webpack and Babel, which help manage module bundling and modern syntax transpilation for Gutenberg block work.

Deployment and Environments

My development workflow centers on predictable deployment. I typically develop on WPEngine for its staging and production branching workflow, and I use Git to manage code. When deploying to WPEngine I follow a Git push pattern that sends code to the correct environment branch defined in configuration.

For database and media synchronization I rely on WP Migrate DB Pro. I automate push and pull operations with a small bash script that orchestrates the full deployment sequence. For example, running project.sh push will:

1. Push code to GitHub.
2. Push code to the appropriate WPEngine remote branch (production or staging), as controlled by the BE_PUSH_TO value in wp-config.php.
3. Push the database and media files via WP Migrate DB Pro using the CLI command wp migratedb profile 1.

Because the CLI accepts only numeric profile IDs, I ensure profiles are created in a consistent order during initial setup. My typical initial setup is:

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 as needed.
4. On local, go to Tools > Migrate DB Pro, choose “Push”, enter the remote connection information, check “Media Files”, and save that profile (I label it “WPE Push”).
5. Create a second profile for pulling from the remote and save it (I label that “WPE Pull”), ensuring the profile order matches the expectations of any CLI scripts.

Editing Production Sites

When clients are hosted on WPEngine, I use Git to move code between development, staging, and production. If a client is hosted on another platform, I use WP Pusher to deploy plugin and theme updates directly to the live site when appropriate. This keeps code deployment reproducible and avoids manual edits on production.

Handling Large Sites and Media

Large sites with extensive media libraries can make local development cumbersome if you try to copy all media. To solve this I use a small utility, BE Media from Production, which rewrites media URLs to point to the production host. This lets me keep themes and plugins local while still displaying the live images.

I place the media rewrite plugin in mu-plugins so it runs automatically, and pair it with a tiny local-settings.php mu-plugin that specifies the production URL to use. This approach reduces the need to sync massive media sets while still allowing accurate visual testing on local environments.

Overall, the goal of my workflow is repeatability: consistent theme structure, a lightweight core plugin for shared functionality, predictable build tools for asset compilation, and automated deployment steps for code, database, and media. These patterns help reduce context switching and make collaboration and maintenance easier over the lifetime of a site.