This post originally appeared on the Strattic.com blog on April 21, 2021.

---

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.

At Strattic, many of our customers are like the ones I described above, and that’s 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.

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.

We’ve all been there, and it’s no fun.

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.

Don’t worry! We’re here to help! 🤓

In this guide, I will also be making use of a premium plugin called WP Migrate DB Pro 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’ve used it on (I’m 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 at Strattic)

Before we get started, there’s some common ground we need to establish.

---

Overview and understanding

In this article, I’ll be referring to the WordPress site hosted on Strattic as your “Production environment” and, assuming you are developing on your laptop or desktop machine, your local development environment as “Local environment” (or just Production and Local, respectively). Please note, on Strattic, there is also a “Live” static site, and a “Preview” static site, which are created or updated when you publish your Production WordPress site.

There are numerous ways you could set up your workflow, and you might also have a “development” environment where your development team tests new features, or a “staging” environment, where your QA team might go through automated and manual testing. The combinations and possibilities are endless, and I’m limiting environments to Production and Local for ease of explanation.

It is also important to think of your WordPress project as three separate pieces:

• Code
• Database
• Media Files (or “Uploads”)

Each of these is distinct in how they should be understood, organized, and managed. Since we’ll be dealing with multiple environments, knowing where your “source of truth” for each of these components is very important. We’ll look at them in the next section.

Syncing vs migration

It’s important to know the difference between “syncing” and “migrating” sites.

• Sync code: This makes sure that both of your sites (Production and Local) are using the same codebase.
• Migrate databases: If you need to have the latest version of the database, it is much better to “migrate” one site’s DB to another. Many companies have tried to build a solution that could sync databases, but a MySQL database is much different than a code repository in structure, purpose, and form. So, we’ll focus on migrating databases, rather than syncing them.

Backups. Ho hum. But seriously.

Always make sure you have a recent backup of at least your Production environment before you attempt to set up a deployment workflow. At Strattic, daily backups are automated, and if you want to trigger a backup, you can do so in your dashboard.

Ok, with these important considerations discussed, let’s look at an overview of the deployment workflow.

The ideal workflow for working with WordPress:

As you might guess, the workflow laid out here is specific to WordPress. The process might differ from other websites or web apps you’ve worked on before.

The workflow can be summed up in this sentence:

“Code goes up, Database and Media Files go down”.

What does this mean in practice?

First, code moves from a Local environment to a Production environment, i.e. up ↑. “Code” is everything you want to version control, typically files ending in a .php, .js, .css, or .html extension (and sure, if you’re doing JSX or React stuff, or Vue stuff, you’re going to version control .jsx, .vue, .whatever files).

The source of truth for the codebase should always be the default, main, or master branch of your Git repository.

Next, database and media files move from the Production environment to the Local environment, i.e. down ↓. Just about everything that is managed in the WordPress admin area (posts, pages, plugin and theme settings) gets saved in the database.Your database should not contain any executable code (though this sometimes occurs when plugins store code in the database). Essentially, if you’re using wp-admin to make and save a change, it’s probably getting saved in the database.

The source of truth for the database of a site should always be the Production database.

Media files (or “uploads”) are typically uploaded through the wp-admin. Some transformations on the images are done based on database settings at that time. The images are not stored in the database, but are stored in a file system. These media files and other uploads are not code, so they don’t need version control. However, you do need to be aware of them, as during a migration and while replacing URL strings, if you don’t move your images from one site to another, image files will break, and other files in the uploads folder (e.g. caching scripts) will break your site.

The source of truth for the media files or uploads of a site should always be the Production database and media files.

This is the workflow we’ll be covering below. The basis for this workflow, I believe, was started by Pantheon here.

However, on Strattic, the workflow and concepts are a little different, since your Live static site is a static replica of your WordPress site, and there is no “database” in a typical WordPress sense.

Ready? Ok, let’s begin.

Step 1: Backup and download your Production site from your host

If you’ve got your Production site running on Strattic, this is the easy part! 😎 Most quality WordPress hosts today, like Strattic, will run daily backups that you can both trigger and access to download. If your current host does not offer this service, consider checking us out!

To use Strattic as an example, go to your dashboard, click on the “WordPress Backups” tab, and download the most recent backup. You may also choose to trigger a backup if you’ve made changes to your site after the most recent daily backup. If you’d like to make an on-demand backup, click “Backup now”.

Once your backup is ready, click the download icon, and wait for your backup file to download. If you have a large site with many media files or your backup is massive, it might take some time. Strattic provides you with a full backup that includes your WordPress core code install, any custom code you’ve added in the wp-content folder,, uploads, and a database export.

Once you have that zip file, you’re ready to move on to the next step.

Step 2: Set up your local development environment

As mentioned above, this guide assumes you already have your favorite local development environment set up. Any of the following options should work for our purposes:

• Local from Flywheel
• XAMPP, WAMP, MAMP
• DesktopServer
• Valet or Homestead (hello Laravel folks!)
• VVV (or any Vagrant and Virtual Box setup)
• WP Local Docker (or any local Docker setup)

If it runs WordPress on your local machine, you should be good to go.

Using your local development environment, set up a fresh install of WordPress. Normally, this includes the latest version of WordPress. If you are looking to use a different version of WordPress than what comes with a fresh install, make sure you install the correct version of WordPress core.

This is now your Local environment.

Once you have everything set up, you can begin to move your code files into your Local environment. Code should always be moved first, before the database is migrated, as the database may rely on some code being present. For example, if you have the default WordPress “Twenty Twenty” theme active on your Production environment, but only have the “Twenty Twenty One” theme installed on your Local, when you migrate the database and media files from Production to Local, you will get a white screen on your local, or if you have WP_DEBUG set to “true”, you might see a warning that says “The theme TwentyTwenty does not exist.”

The wp-content folder is the directory where you should make and keep all custom aspects of your WordPress installation. This includes the plugins, mu-plugins, themes, and uploads directories. Other commercial and community plugins also tend to make use of this directory as well to store generated PHP, JS, JSON, or media files needed by their plugins.

In most cases you just need to copy over your wp-content folder from the backup you got from your Strattic dashboard. Of course, this will also bring over the wp-content/uploads folder which has your media files in it, which is exactly what we want, as we’ll see in the next step.

Once your code is copied over from your Production to your Local, it’s time to migrate the database.

Step 3: Migrate your database and media files from Production to Local

This is the final step in bringing your Production environment to your Local environment. To do this, we will migrate the Production database and media files from Production to Local. As mentioned above, we will use the WP Migrate DB Pro plugin with the Media Files addon to accomplish the migration.

If you haven’t already, download the core WP Migrate DB Pro plugin and the media files addon from your account on DeliciousBrains.com. Install and activate both plugins on both your Production and Local environments.

When you activate the plugins, you’ll get a notification on the WordPress Plugins page that you need to activate your license key. Click on the provided link, which will take you into the WP Migrate DB Pro settings. On that page, do the following:

• Enter the license key (this can be done on both installs).
• Set the “Permissions” in Production environment to “Pull” and in your Local environment to “Push”, this will keep you overwriting your Production database with your Local (or another) database.
• Click “Copy to Clipboard” from the “Connection Info” from the Production environment – you’ll need that soon for your Local environment (this connection information is randomly generated by the plugin).

Your Production environment settings page should look something like this:

Great! You are now ready to pull your Production database and media files to your Local environment.

Now, on your Local environment, navigate to the WP Migrate DB Pro Migrate tab, and select “Pull” to start a migration profile:

Paste in the connection info you copied from your Production site to your Local and click “Connect”. Since you will be pulling from your Production environment on Strattic, you’ll also need to provide the HTTP Auth for your site. This can be found in your Strattic dashboard under the site details.

Once connected, you’ll be able to configure the migration. To get started, configure the following:

• Tables: Leave “Migrate all tables…” selected – we’re going to migrate all tables
• Excluded Post Types: Leave this unchecked
• Advanced Options: Leave the defaults marked (replace GUIDs and exclude transients), unless these need to change for your setup
• Backup the local database before replacing it: check this, and keep “backup all tables…” selected. This backs up your current database if you need to restore it later.
• Media Files: Check this and leave the default “compare then download” marked. You can explore the differences, but this should be fine for now since we’ve just downloaded a fresh backup that has all the media files in it already.
• Save Migration Profile: check this and save your configuration, giving it a unique name (e.g. “full PULL from PROD” would mean that this is pulling everything from Production).

Your migration profile settings should look like this:

Once you click “Pull & Save” the migration will run through these steps for you:

• backup your local database
• migrate the database tables from the Production environment
• compare the media files with what’s on your Local to Production, and download anything that is new or different.

You should then see this success message:

If you get any errors, refresh the page and try again, as sometimes the first migration takes a little while and can time out.

Once the migration completes, you will be asked to log in again, but your database, media files, and code should all be on your Local environment now.

One of the benefits of using WP Migrate DB Pro are the Migration Profiles. In our example above, you only need to set up this profile once. From now on whenever you need to re-run the migration, you can click on the profile, and click “Pull and Save” again, and your migration will run again.

Easy, peasy, lemon squeezy 🍋 😌 .

If you’d like to know about other database migration options available, I’ve listed some at the end of this article.

Step 4: Put your Local code under version control and create a remote repository

Now that you have your Local environment set up and your Production site database and media files migrated to your Local environment, it’s time to put your local code under version control. Not only will this allow you to track code changes, roll back mistakes, and and better collaborate with your team, once your code is version controlled, you can set up a deployment pipeline to automatically deploy your Local code to Production after you make changes to the files, commit them, and push them up to a remote repository.

This is very nice, no more clicking and dragging files via your SFTP client 👍 😎 .

While this guide does assume you’ve used Git and version control before, we have a few recommendations and best practices to keep in mind when integrating your repository and Strattic’s platform:

• DO NOT overwrite or track your wp-config.php file! This file contains Strattic configurations, your database passwords, salts, and other configurations. It should NOT be overwritten or exposed in a repository.
• Make sure you’re using a Strattic-compatible .gitignore file:
  • You should probably have the .gitignore file in the WordPress root directory (where the wp-admin, wp-content, wp-includes directories are).
  • This gist is an example of how to ignore WordPress core files.
  • As an alternative, this gist is more strict and will only track changes in the mu-plugins, plugins, and themes directories of your wp-content directory.
  • If you are using any “mu-plugins”, make sure you are tracking the mu-plugins directory. If not, it can be ignored (just make sure to ignore the ludicrous directory and the strattic.php files in your .gitignore, since these should not be changed or removed).
• Only deploy code to Strattic, not your entire WordPress instance. So, for example, don’t deploy files like images, PDFs, CSV, etc., unless you’re confident in what you’re doing, or that’s your process.

The main files for version control are going to be in wp-content, which includes the mu-plugins, plugins, and themes directories. Any other code files or folders that need to be tracked can and should be added in the wp-content directory.

Since you’re deploying from a repository, make sure to follow the workflow we’re discussing for creating changes like adding posts, images, or updating styles and functionality. As described above, the best way to think about this code going “up” from your Local environment to your Production environment, and the Production database and media files going “down” to your Local environment.

Again, these are all just recommendations, and you know your site and version control needs best.

If anything goes wrong, we always have a daily backup of your site which you can access in your Strattic Dashboard #safetyfirst 🤓 .

Once you have your code under version control, make sure to deploy it to a remote repository. There are many services available for this, like Github, Gitlab, Bitbucket, and more, and most have a free tier. If your organization has a self-hosted repository and requires its use, use that for your remote.

Now we’re ready to set up our deployment automation, but we’re going to give you a choice between two services we like (kinda like the “choose your own adventure” stories we used to read and love 🤓): Buddy and DeployHQ.

Spoiler alert!: Either option will get you where you want to go 😃… and you won’t be chased by a bear or fall off a cliff.

To get started with Buddy, just continue scrolling.

To get started with DeployHQ, click here.

Step 5, Option 1: Set up Buddy to deploy your Local code to the Production server

In order to deploy a code repository on Strattic, we recommend using a tool like Buddy. This allows for the repository to be deployed via SFTP. Tools like Buddy track your commits and run a script to move your code from the repository to the server.

Ok, let’s get going!

To follow along with this part of the guide, make sure you have:

1. A Git repository on Github, Gitlab, Bitbucket, or self-hosted
2. An account on Buddy (On the free tier, you can deploy 1 to 5 projects up to 120 times total a month!)
3. Your site’s SFTP credentials, which can be found in your Strattic Dashboard

If you haven’t already, go to Buddy and create a free account. You’ll get an email to verify your email address, make sure you verify your email or you won’t be able to move on to the next step or deploy.

Already have an account? Make sure you sign in.

That was fast! Onward!

If you’ve just signed up for Buddy, you were probably greeted with a “Create a Project” button:

If you already have an account or got lost along the way, you can always go to your Buddy Dashboard or Projects tab and click “Create a new project”.

Once you do that, you’re greeted with the following:

Add a new name for your Production site. If your repository is on one of the listed services, you can click on the service and authenticate yourself. You will then be able to choose the repository you want to integrate on Buddy.

Once you locate the repository you want to deploy, click on it. Buddy will authorize it, add its deploy keys to the repository, and then take you to the new project where you will see the option to “Add a new pipeline”:

Note: Buddy will automatically detect if your repository is primarily PHP (in the case of WordPress) or if you’re running a headless/decoupled WordPress setup, and your project is primarily React or Vue, you’ll see something different.

Pipelines are a set of tasks performed in the context of a selected repository. To set up the pipeline, you’ll need your SFTP credentials from your Strattic Dashboard. Once you’re in the dashboard, click the “Details” button of the site you want to integrate.

From there, under the “Connection Info” tab, you can get your SFTP credentials:

Now it’s time to set up your Buddy pipeline. You should see a screen like this:

In order to set up the server you’ll need to do the following:

1. Name the Pipeline (something like “Production Deployment”, or “Deploy to Strattic”).
2. Trigger Mode: selecting manual will require you to manually deploy from the Buddy app, or if you select “On push”, code will be automatically deployed on push to that repository branch.
3. Branch or tag: for now, leave as “Single branch” and the “master” branch (or whatever your default branch is).

Now click on “add action” to go to the next screen:

Click the button “Transfer files via SSH-FTP” and enter the following:

1. Keep “GitHub repository” selected, unless you want artifacts on Buddy.
2. Keep the “source path” as is.
3. “Use proxy” can remain off.
4. Under Destination Server, use the following from your Strattic Dashboard:
   1. “Hostname” is the value from “SFTP Address/Host”.
   2. “Port” is the value from “Port”.
   3. “Login” is the value from “User Name”.
   4. “Password” is the value from “Password”.
   5. In “Remote Path”, input /public_html, this assumes your repository is based in the WordPress root as mentioned above.
5. Under Settings
   1. “Delete files on server” can remain On.
   2. “Use temporary files” can remain Off.
6. Click “Add this action”

You should be greeted with the following screen:

You can click the big, blue “Run pipeline” button, fill out any comments you like, and then click the big blue “Run now” button.

This will deploy the commit/s and you’ll be able to watch the progress. If there are any issues, please check your logs, reference Buddy’s Help and Support, and feel free to reach out to us as well.

Note: Depending on the size of your repository, your first deployment may take some time to complete. Subsequent deployments should go much faster and they’re only deploying the changes you made in the code.

If you need more information, you can find help here or contact Buddy for more information.

As noted above, you can also change the setting to deploy on push to the repository. You can do this by going to the Settings in the pipeline and changing the Trigger Mode to “On push”.

Otherwise, if you see a screen like this, your deployment was successful:

Congratulations!!! You have successfully deployed your website to Production!!!
🥳.  🎉.  🎊

Step 5, Option 2: Set up DeployHQ to deploy your Local code to the Production server

In order to deploy a code repository on Strattic, we recommend using a tool like DeployHQ. This allows for the repository to be deployed via SFTP. Tools like DeployHQ track your commits and run a script to move your code from the repository to the server.

Ok, let’s get going!

To follow along with this part of the guide, make sure you have:

A Git repository on Github, Gitlab, Bitbucket, or self-hosted
An account on DeployHQ (On the free tier, you can deploy 1 project up to 10 times a day!)
Your site’s SFTP credentials, which can be found in your Strattic Dashboard

If you haven’t already, go to DeployHQ and create a free account. You’ll get an email to verify your email address, make sure you verify your email or you won’t be able to move on to the next step or deploy.

Already have an account? Make sure you sign in.

That was fast! Onward!

If you’ve just signed up for DeployHQ, you were probably greeted with a “Create a Project” button:

If you already have an account or got lost along the way, you can always go to your DeployHQ Dashboard or Projects tab and click “Create a Project” or “New Project”.

Once you do that, you’re greeted with the following:

Add a new name for your Production site. If your repository is on one of the listed services, you can click on the service and authenticate yourself. You will then be able to choose the repository you want to integrate on DeployHQ.

Alternatively, if you’re self hosting your repository, or the service you use is not listed, you can check “Add your repository details manually?”.

If you do add your repository manually, you’ll be greeted with and need to add the following details to your repository and to DeployHQ:

Otherwise, you can authenticate and search for your repository

Once you locate the repository you want to deploy, click on it. DeployHQ will authorize it, add its deploy keys to the repository, and then take you to the “New Server” setup.

To set up the server, you’ll need your SFTP credentials from your Strattic Dashboard. Once you’re in the dashboard, click the “Details” button of the site you want to integrate.

From there, under the “Connection Info” tab, you can get your SFTP credentials:

Now it’s time to set up your DeployHQ server. You should see a screen like this:

In order to set up the server you’ll need to do the following:

• Name the Server (something like “Production Deployment”).
• Click on the SSH/SFTP button.
• Under SSH Configuration, input the following from your Strattic SFTP credentials:
  1. “Hostname” is the value from “SFTP Address/Host”.
  2. “Port” is the value from “Port”.
  3. “Username” is the value from “User Name”.
  4. “Password” is the value from “Password”.
  5. Leave “Use SSH key rather than password for authentication?” unchecked.
  6. In “Deployment Path”, input /public_html, this assumes your repository is based in the WordPress root as mentioned above.
  7. Leave the “Unlink existing file before uploading new version?” and “Perform zero-downtime deployments on this server?” boxes unchecked.
• Under Deployment Options
  1. Select the branch to deploy from (“master” is default, but you can select any branch)
  2. If you would like the branch to automatically deploy when pushed to, you can check the “Automatically deploy when this branch is pushed to?” box.
  3. Label the Environment whatever you like, e.g. “Production”.
  4. Unless you have a custom deployment situation, you can probably leave “Subdirectory to deploy from” blank.
• Under Notification Options:
  1. You can select when notifications should be sent. To start, we recommend “Always Notify” while you’re getting comfortable with DeployHQ, otherwise you can always leave it on the “Only notify if a deployment fails” option.
  2. If you do want to receive notifications, enter your email address.
• Under User Permissions:
  1. Currently, you probably do not need to change this. However, if you build out multiple deployments and projects with a larger team, these options allow you to select who has permission to deploy.

Now, click “Create Server”. If there are any errors, your should be able to fix them, or reach out to DeployHQ’s support for help and guidance.

Once the server is created, you’re ready for deployment.

You’ll want to run your first deployment manually. The rest can be done automatically when code is pushed to whatever branch you indicated in the deployment server settings.

To make a deployment, click on “Deployments” and then the “New Deployment” button or “Deploy Project” button, either will take you to the same manual deployment screen.

From here, you will see the following:

1. Deploy Limit: if you’re on the free plan, you have 10 deployments a day you can use.
2. Servers: this will list the Server you set up in the last step, or any other servers you have available to deploy.
3. Branch: the selected branch you want to deploy from. This can be changed if there is more than one branch.
4. Start Revision: if you’ve deployed before, this will show the last commit DeployHQ deployed. You can choose a different commit or enter one manually.
5. End Revision: this will show the most recent commit that DeployHQ will deploy. You can choose a different commit or enter one manually.
6. Schedule Deployment: this allows you to run the deployment immediately or schedule it to deploy in the future.

Once you’re satisfied with the options, you can “Preview” or “Deploy”.

“Preview” will allow you to see what will be deployed and if it will most likely succeed.

“Deploy” will deploy the commit/s and you’ll be able to watch the progress. If there are any issues, please check your logs, reference DeployHQ’s Help and Support, and feel free to reach out to us as well.

Note: Depending on the size of your repository, your first deployment may take some time to complete. Subsequent deployments should go much faster and they’re only deploying the changes you made in the code.

If you need more information, you can find help here or contact DeployHQ for more information.

Congratulations!!! You have successfully deployed your website to Production!!!

🥳    🎉.   🎊

The Next Step: Make changes locally in code and deploy them automatically to your Production server

This last step is really just icing on the deployment cake.

Now that you have your Production environment ready to receive deployments and your Local environment set up to receive database and media file migrations as well as your code version controlled and connected to a remote repository, which will automatically deploy to your production environment, you’re ready to make changes to your Local codebase.

You will find example workflows next, but the idea now is that you can do the deploy the following code changes from your Local environment to Production with ease:

• Installing a new plugin or theme
• Making style changes to CSS or Sass/SCSS files
• Updating PHP template or function files
• Incorporating new JS files and functionality

All of these code changes can be made locally, committed, pushed to your remote repository, and automatically deployed to your Production environment with just a few clicks or console commands.

Now, let’s put it all together.

Example 1: Workflow on Strattic with a new site:

• Develop Locally
• Deploy to Production
• Publish to Live static site

This assumes you’ve got your website set up on a Local environment how you like it.

1. Put your Local codebase under version control and set up a repository on your host of choice (e.g. Gitlab, Github, Bitbucket, etc.).
2. If you’re using Migrate DB Pro and the Media Files add-on, make sure it’s in your codebase and in version control.
3. Set up your deployment to Strattic with Buddy or DeployHQ.
4. Deploy your code to Strattic. Now your Local code should be on Strattic’s Production environment.
5. Set up your Migrate DB Pro connection between your Local and Production environments.
6. Push your database and media files from Local to Production. Migrate DB Pro handles the search and replace, serialized data, and flushes the cache and permalinks.
7. Your Local site should now be on Production, and you should be able to click on the Strattic Publish to generate the static version of your site.

Example 2: Workflow on Strattic to update a site:

• Get Backup from Production
• Develop Locally
• Deploy to Production
• Publish to Live static site

This assumes you’ve got your website set up on Strattic’s Production environment, your code is not yet under version control, and you want to set up a new local environment to make changes and deploy those changes back to Strattic.

1. If you’re using Migrate DB Pro and the Media Files add-on, make sure it’s in your Production codebase.
2. Backup your site on Strattic and download the codebase, database, and media files (i.e., the entire zip).
3. Bring that code into your fresh Local setup, however you normally do.
4. Set up your Migrate DB Pro connection to be your Local and Production environments.
5. Pull your database and media files from Production to Local. Migrate DB Pro handles the search and replace, serialized data, and flushes the cache and permalinks.
6. Put your Local code under version control.
7. Set up your deployment to Strattic with Buddy or DeployHQ.
8. Deploy your code to Strattic. Now your Local code should be on Strattic’s Production environment (and in this case, nothing has actually changed, because it was the code that was already there, the only difference is that now it’s all version controlled).
9. Make any code changes you like, commit them, and push them to your Git repo, which can automatically deploy them to Strattic if you have that set up.
10. Push your database and media files from Local to Production. As before, Migrate DB Pro handles the search and replace, serialized data, and flushes the cache and permalinks.
11. Your Local site should now be on Production, and you should be able to click on the Strattic Publish to generate the static version of your site.

Example 3: On Using Multiple Environments:

• Local
• A Development Environment on or off Strattic
• Strattic’s Production
• Publish to Live statice site

Let’s say you’re in a situation where you have a dev team that normally tests their work locally, but sometimes use a hosted Development environment to show some experimental work or get another person to QA / UAT. You also try to keep Development identical to Strattic’s Production so it can be used to test deploys and configuration issues. What do you do here?

Use the previous examples to make sure that your codebase is under version control and Migrate DB Pro is set up on all environments.

Make sure you’re using a good Git workflow, there are several options like Github flow, feature branching, and the Nvie model. Let’s assume though your production branch is main and your development branch is develop and all feature branches merge into develop.

1. Set up the Development environment as a mirror of Production.
2. Developers make their changes via feature branches and those get merged into develop which gets deployed to the Development environment.
3. Developers or content administrators can then make their test changes on the Development environment, and QA/UAT those changes.
4. Then, if all is well, the code can be merged into main , which can then be deployed to Strattic’s Production environment.
5. The updates can be made there as well, tested again, and then everything can be published to Live.
6. Critical Note: even though you’re able to migrate databases, in this case, you should never migrate a database from Development to Production as you will lose Live data (forms, comments, anything else that is integrated to your Production environment with Strattic). Of course, you can always migrate from Development to Production if you’re confident in your workflow, and there’s nothing dynamic on your Production environment you are worried about losing (i.e., you’ve got a “read only” site with no contact forms, comments, etc.).

Aaaand that’s a wrap

We hope this guide has been helpful and shown you a path for yourself or your team to create a workflow and deployment system that works for you on Strattic or anywhere else you choose to host your site.

While this guide focused on one way to run a workflow and deployment system for your WordPress project, there are many ways and tools available to create your or your team’s ideal workflow. For example, CodeShip and BranchCI could be used for deployments instead of Buddy or DeployHQ, and WP-CLI or the InterconnectIT Search and Replace plugin to update your database export on Local. We’ve tried to pick out the tools in this guide that are reliable, user friendly, and remember your deployment settings for the next deploy. Feel free to test other tools and adjust your workflow to your needs accordingly .

As always, we’re here to help and available if you have any questions, please feel free to reach out and ask!