I have a number of clients who host sites on WP Engine, and I've become a fan of the service. What you give up in flexibility that a vanilla hosting account provides you more than gain back in performance and robust WordPress tools. The fact that I've been able to talk with a knowledgeable rep on live chat with almost no wait time has been a nice bonus.
WP Engine has git based deployment support. While I still prefer subversion over git, this solution does elegantly solve the problem of deploying content to server with a minimum of confusion.
My standard practice is as follows: after a release I fork off a release branch that is used to host urgent bug fixes. The fixes are eventually merged back into master. At the next deployment, I fork off a new release branch, discarding the old one. And repeat. This approach has served me well for years now.
A week ago, I ran into a significant gotcha: I needed to deploy a fix that had been made on the release branch. However, WP Engine assumes that all deployments are associated with master. In other words, I could make changes to my branch release-2, and I could push that branch to WP Engine, but it wasn't going to actually deploy those files.
After much Googling I arrived at the following recipe:
git push -n production release-2:master
That is, push release-2 to master on the remote named production.
This worked. Every once in a while, git surprises me with actually simplifying matters, and it did so in this case. It's still too early to tell how this work-around is going to play for the next release. But at least I got my bug fix deployed in an orderly way. The alternative was to drop back to using sftp and that's no fun at all.
Hi Ben. Is it the same as pushing the desired commits from release-2 into bugfixes and then and then pushing bugfixes into master and then pushing master to its remote?
ReplyDelete