WP Engine supports a variety of different development workflow methods. However, there are some best practices for site development that you should keep in mind. Let’s take a look.
Best Practices
Before we dive in, let’s cover some basics of development best practices. These practices are especially important when managing multiple copies of the same site. By sticking to these simple rules, you can help ensure you don’t overwrite important information on your production site when making changes.
Databases move down, Code moves up
In this article, the core concept we’ll be discussing is: “Databases move down, code moves up.” This means that database data should move “down” through your environments (the “bottom” being your local dev environment). And site code should move “up” through your environments (the “top” being production). Within this concept there are a couple key principles to keep in mind:
Manage content with version control
A general principle in modern software development is that version control (and git in particular) is the right way to manage the filesystem. Using SFTP to manage the filesystem on a server is less ideal because it is:
- Slower
- Harder to roll-back
- Harder to audit
- Unable to be branched
- Does not integrate well with modern development systems
Using git you can streamline your workflow, especially when working with a team. Since git allows for notes, pulling down changes pushed by other developers, and unique IDs for every push, it’s easy to determine what change was made by who, when, and for what reason. Additionally, git is ideal when working with large sites. Only the files you choose are pushed, which shortens your deploy process when compared to a full site copy.
When using git you will need to set up a local development environment. You can use the steps from the WordPress Developer Guide to get started. Once your environment is created, follow the steps in our git guide to get ready to deploy. It’s also a good idea to look into Continuous Integration solutions to help automate, test, and deploy your builds.
Don’t copy databases into production
Another general principle in modern software development is that you should not blindly copy database data into production environments. Instead, it’s best practice to have a defined process for changing production data. The reasoning for this is two-fold. Firstly, production data is in a constant state of flux. So, “copying over” a database from your development instance can destroy new, live data. Second, you may also need to branch and merge changes to the database along with code changes in development. With that in mind, the logic that makes those changes should also be in code.
Copying the database “down” works equally well with databases of any size, as your development instances would be the ones in flux as the database changes are being applied.
Defining Workspaces
Before you deploy your site, you’ll need to set up a “Workspace.” Workspaces are used to define development projects. For instance, if I have four WordPress installs all related to the same project, I would group those in a Workspace. In the example below, my Workspace is called “Beverage Co.”
Add Environment Labels
Beyond the initial Workspace group you should define the role each WordPress installation plays in your development workflow. Within the “Beverage Co” group, for instance, I have four distinct environments: Dev, QA, Review, and Prod.
Deploying your Site
Now that you’ve defined your Workspaces and Environments, you can begin to deploy your site. Be sure to follow the steps below in order, according to the “Copy databases down, Copy code up” method.
Step 1: Copy databases down
The first step in deploying is to “Copy databases down.” This means copying your production database using the “Deploy site” method down to staging or development instances.
You can use this tool within the User Portal to “Copy databases down” to your instances which are hosted by WP Engine. However, to copy your database to your local environment you will need to obtain a backup of your database. The most simple method is to download a backup point. Within the “Download ZIP” options you will see the choice to select a recent database backup. Alternatively, you can export your database via phpMyAdmin.
Step 2: Deploy code up
Once you have finished copying the database down, you can begin the second step: code deploys. The code changes should be deployed using git. After reviewing the changes in your development instances, deploy the code to your production instance using git. This ensures only the filesystem is being overwritten, and the live database remains unchanged.
Remember: when deploying it’s a good idea to utilize a Continuous Integration (CI) tool to automate your deploy workflow. CI helps keep team projects on schedule by integrating code from all team members on a daily (or frequent) basis, and verifying it against automated tests.
When using git, it is always best practice to only make filesystem changes locally, and not within the WordPress Admin Dashboard or via SFTP. This means adding and editing plugins and themes should only be done via git. WordPress Core files, however, are something WP Engine updates for you. With that in mind, there are two methods to manage WordPress Core files when using git:
Manage all files with git, making filesystem read-only. With this method WP Engine will update your WordPress Core files when updates are released, and push the changes to the remote repository. When you receive an email notification from WP Engine that WordPress Core updates have been performed, use git pull to pull down the updated files.
Ignore WordPress Core files. In this method, WP Engine still manages WordPress Core file updates, however, your WordPress core files should be ignored locally in the .gitignore file. This means any changes to WordPress Core files locally will not be pushed via git, and will not overwrite WordPress Core updates.
Please note: While there is the option to use “Deploy site” to do a full deploy between a development instance and your production site, we strongly recommend the “Databases move down, Code moves up” workflow. This option exists for developers not leveraging version control for their sites.