Development Best Practices (with Version Control)

WP Engine supports a variety of different development workflow methods. There are general best practices for site development that you should keep in mind. By sticking to these general rules, you can help ensure you don’t overwrite important information on your Production site when making changes. These practices are especially important when managing multiple copies of the same site.

---

Database Moves Down, Code Moves Up

The “top” layer in this scenario is your live or Production environment.

The “bottom” layer is the environment you’re developing in. This may be Staging, Development or your local development environment.

Therefore, code moves up to Production and the database moves down to develop.

It is never advised to include a database when copying to a live site.

You should never 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:

1. Production data is in a constant state of flux.
   • Copying a database from your development instance will destroy newly added, live data.
2. You may also need to branch and merge changes to the database along with code changes made in development.
   • With that in mind, the logic that makes those changes should also be in the code instead.

Copying the database “down” works equally well with databases of any size, as your development instances would be the ones in flux when the database changes are being applied.

---

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’s slow, difficult to rollback or audit and can’t be branched.

Using Git you can streamline your workflow, especially when working with a team. Git allows for notes, pulling down changes pushed by other developers, and unique IDs for every push. This makes it 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.

Before you use Git you will need to set up a local development environment.

Local Development Options

1. Local – Integrates directly with WP Engine with an easy-to-use GUI for setup and copy
2. WordPress Developer Guide – Setup a local WordPress development environment manually

Once your environment is created, follow the steps in our Git guide to get ready to deploy.

Continuous Integration

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.

---

Deploy Site

Now that you’ve defined your Workspaces and Environments, you can begin to deploy your site.

1. Copy database down
   • Copy to your local dev environment
     • Local allows for copying from WP Engine to a local environment through their interface
     • Other local setups will require you download a backup or export your database and import it to local
2. Deploy code up
   • After changes are developed, copy the file changes to Production
     • Code changes should be deployed from local dev to Production using Git. As databases cannot be pushed with Git, this ensures only the specific files push are overwritten.

Deploy Site When Not Leveraging Version Control

It’s always preferred to develop locally and leverage version control such as Git. However, if you choose to develop on a Staging/Development environment instead, refer to the workflow in this guide instead.

---

WordPress Core File Updates

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.

Keep WordPress Core Files Versioned

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.

To set your file system as read only, you can reach out to WP Engine Support.

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.

---

NEXT STEP: Getting started with Git