One of my favorite features of WPEngine is their integrated
git push for deployment. Instead of manually SFTP’ing files back and forth, you can easily push code changes while keeping your code version controlled.
WPEngine lets you create unlimited transferrable installs, so you can easily use it for all your site development. When it’s time to go live, you simply type in your client’s email address and they’ll get a direct email walking them through the transfer process.
Create a site on WPEngine
From your WPEngine dashboard, click “Add Install” and give it a name. Once created, you can clone an existing live site here by installing the WPEngine Automated Migration plugin on the live site, typing in your WPE install details, and letting it handle the migration of everything.
Once the install has been created, click “Git Push” in the sidebar, type in your name, and paste your SSH public key. This support article by WPEngine will walk you through it.
Open Terminal and initialize git in the top level of the website:
git init. While you could use it to version control everything (WP core, themes, plugins…), it makes sense to limit it to just the code you’re actively editing using a .gitignore file. I limit it to my custom theme and core functionality plugin. Here’s my gitignore file.
If you’ve created a repo on GitHub, click “Clone or Download” (screenshot), copy the URL they give you, and set it up as a remote. For instance, for my EA Starter theme I would use:
git remote add origin [email protected]:billerickson/EA-Starter.git
Go back to the Git Push page in the WPEngine dashboard. In the bottom of the right column you’ll see the two remotes corresponding to your production and staging environment. Add them (make sure you use the correct URL). Example:
git remote add production [email protected]:production/mysite.git git remote add staging [email protected]/mysite.git
Pushing code updates
As you develop your site, periodically commit your changes:
git commit -am 'this is my great commit message'. Push those changes to GitHub:
git push origin master. And when you’re ready to push to your production or staging site, simply push to the remote:
git push production master.
WPEngine will scan the files, make sure there’s no PHP errors, update the correct files, and clear your cache.
I also recommend using WP Migrate DB Pro to push/pull your database and media. If your site has lots of media, skip the media syncing and use BE Media from Production so that your local install will reference the production site for media rather than having to store a copy of everything locally.
You can also migrate entire environments through the WPEngine portal. When you enable the Multi-Environment Site feature, you’ll get three environments: Production, Staging, and Development.
When we are redesigning a website that’s already hosted on WPEngine, we’ll copy the production site to development and build our new theme there. When it’s time to go live, we can push the development environment to production.
We often work with food bloggers and publishers who have dozens of new posts and thousands of comments created during the development process, and we don’t want to lose it. When it’s time to launch the new site, we use the following approach to migration:
- Implement a “content freeze” on production. The client should not create or edit any content between now and completion of the redesign launch.
- Make a fresh backup of all three envrionments.
- Deploy the latest production backup to the staging environment
git push staging masterto push the code updates to the staging environment.
- Rebuild everything on staging: setup new plugins, menus, widgets, forms, and update any pages that need new content (ex: Home)
- Do a final review of the staging site with the client.
- Once approved, deploy the staging environment to production, overwriting the production files and database.
Minimize downtime with a hidden feature flag
When you deploy the staging environment to production, the production site becomes inaccessible until the migration is complete. This was by design so there isn’t any data lost during the migration, like ecommerce sales that occur after you press “Deploy” but before the new database is in place.
However, for our clients, we would rather have a few lost comments than an hour of downtime when pushing a large site to production.
There is an unpublished feature that can help. Open up a support chat and request the ‘clone_site_use_deploy_dir’ site config option for the specific install. Since this is a hidden feature, the first person you chat with may be confused so you may need to ask them to escalate.
Once enabled, instead of copying the source site directly to the target site, WPEngine will now copy source to a temporary directory and database, do the data munging (search-replace) on the temporary location, and then move the temporary location to the target. This way the target site doesn’t change while the data munging is happening. The only downtime incurred is the time taken to do the move.
We request this feature flag for all of our clients and have had no noticeable downtime during deployments.
Be careful though. Since the target site is now available during the time of the copy, it introduces potential data loss issues. If any data is written to the target site while the copy is happening, that data will be lost at the end of the copy since it gets overwritten by source. I wouldn’t recommend this approach where important data might be collected during the migration, like ecommerce or membership sites.