{"id":3335,"date":"2021-07-26T15:18:00","date_gmt":"2021-07-26T20:18:00","guid":{"rendered":"https:\/\/n8finch2024.local\/?p=3335"},"modified":"2024-02-26T21:54:22","modified_gmt":"2024-02-27T03:54:22","slug":"an-ideal-wordpress-development-and-deployment-workflow-using-wp-migrate-db-pro-and-deployhq-or-buddy","status":"publish","type":"post","link":"https:\/\/n8finch2024.local\/an-ideal-wordpress-development-and-deployment-workflow-using-wp-migrate-db-pro-and-deployhq-or-buddy\/","title":{"rendered":"An Ideal WordPress Development and Deployment Workflow using WP Migrate DB Pro and DeployHQ or Buddy"},"content":{"rendered":"\n

This post originally appeared on the Strattic.com<\/a><\/strong> blog on April 21, 2021<\/em>.<\/p>\n\n\n\n

\n\n\n\n

WordPress has a reputation for being an old-school piece of software, but while it runs on what is perceived as a legacy server stack, it can most definitely be used in conjunction with modern web development workflows. Many developers around the globe are busy building large-scale, sophisticated WordPress projects, and utilize such techniques as CI\/CD and version control (gasp!) while doing so.<\/p>\n\n\n\n

At Strattic, many of our customers are like the ones I described above, and that\u2019s why we often get asked about how to set up development and deployment workflows with WordPress in general, and with static WordPress specifically. There are many ways to do this, and many great solutions out there that try to make CI\/CD with WordPress a breeze.<\/p>\n\n\n\n

While our mission at Strattic is to make WordPress sites faster, more scalable, and completely secure, we also aim to help teams of developers and stakeholders be efficient and effective in managing and growing their sites. This post aims to do just that: help you build and utilize a workflow that allows you to both keep your code under version control, while not worrying about overwriting your production database.<\/p>\n\n\n\n

We\u2019ve all been there, and it\u2019s no fun.<\/p>\n\n\n\n

This guide assumes that you have a working knowledge of setting up a local development environment, a production site (hopefully on Strattic!), knowledge of Git and version control, and you need to manage multiple environments and components without losing your mind.<\/p>\n\n\n\n

Don\u2019t worry! We\u2019re here to help! 🤓<\/p>\n\n\n\n

In this guide, I will also be making use of a premium plugin called WP Migrate DB Pro<\/a> with its Media Files addon, which handles database and media files migration, as well as serialized search and replace, migration profile creation, and one-click migrations. I\u2019ve used it on (I\u2019m not exaggerating) hundreds of sites over the last half-decade and can only sing its praises. There are other migration tools available, but this one takes the cake! (And you know we love cake<\/a> at Strattic)<\/p>\n\n\n\n

Before we get started, there\u2019s some common ground we need to establish.<\/p>\n\n\n\n

\n\n\n\n

Overview and understanding<\/h2>\n\n\n\n

In this article, I\u2019ll be referring to the WordPress site hosted on Strattic as your \u201cProduction environment\u201d and, assuming you are developing on your laptop or desktop machine, your local development environment as \u201cLocal environment\u201d (or just Production and Local, respectively). Please note, on Strattic, there is also a \u201cLive\u201d static site, and a \u201cPreview\u201d static site, which are created or updated when you publish your Production WordPress site.<\/p>\n\n\n\n

There are numerous ways you could set up your workflow, and you might also have a \u201cdevelopment\u201d environment where your development team tests new features, or a \u201cstaging\u201d environment, where your QA team might go through automated and manual testing. The combinations and possibilities are endless, and I\u2019m limiting environments to Production and Local for ease of explanation.<\/p>\n\n\n\n

It is also important to think of your WordPress project as three separate pieces:<\/p>\n\n\n\n