Please take the time to read through or you will not get it. Then you just wasted a click and bandwidth. The idea behind this git workflow for WP Engine is to have the most flexibility. The code and practice that follows is to track all WP Engine environments separately in git branches on your local machine. To be able to develop on the master branch and be able to do continuous delivery from on stage and prod branches.
Basically in order to do that wee need 3 branches on our local machines. Each developer will have the same branches and will be tracking the same thing.
This way we have our local branches
master
–tracking- Development remote on WP enginestage
–tracking- Staging remote on WP engineprod
–tracking- Production remote on WP engine
Now you have all the flexibility that you can have the following workflow
Git Workflow
- Multiple developers can be working on their own master branch, even spin off new branches from them to work on specific features if they need
- each of you can have your own local branches to work on specific features, as they will all be created from master
- each feature branch should be named by ticket number like
feature-122
orfeature-128
- and as you are done you just locally merge it in to master
- Once it is ready to demo to the QA team all you need to do is push master up to Development remote on WP engine for a demo
- Once QA approves, you can locally merge
master
into localstage
(which tracks WP engine Staging environment) quickly push it up for Client review and approval on stage branch- if not all the changes have been approved by QA, not a problem then only merge that specific feature branch into your local
stage
- if only certain commits are good, still not a problem, then cherry pick those commits from local
master
(which track WP Engine Dev) intostage
(which tracks WP Engine Stage) and push on stage
- if not all the changes have been approved by QA, not a problem then only merge that specific feature branch into your local
- Periodically when it’s deploy day you can locally merge your whole
stage
branch into localprod
branch and up she goes to the WP engine Production environment - But wait there is more! If a hot fix is needed for prod environment, you can use your local
prod
branch to quickly commit a change and up she goes to Production WP Engine Environment.- you just need to make sure once the hotfix is done to merge your local prod branch into your local dev and stage and do a push on those as well so other developers get the fix as well. So they don’t override it with their next push to prod.
Here is how you set it up
OK, so I am assuming by now you have logged in to WP engine, set up the environments there Production, Staging, and Development and you added your public keys to all environments. Just go to WP engine Dashboard and make sure you have that. OK, beautiful. Now for the sake of making this easy let’s use XYZZ as a project name example
So when you are on the WP engine dashboard under the Production Tab under “git push sub tab you have this
[dev_git_url] = [email protected]:production/xyzz.git
Then under stage you have
[stage_git_url] [email protected]:production/xyzzstg.git
And under the Development tab you have
[prod_git_url] [email protected]:production/xyzzdev.git
OK now we get to work on your local machine. Before we do that just know we don’t track WordPress core in git. It is completely managed by WP engine.
So we will be adding this git ignore file as soon as we clone the repository.
// visit and download this
https://gist.github.com/lehelmatyus/7ca04af6be50c8f48dfb81dd8c5913e4
k so now we can start.
Set up the git workflow and branches
Before you begin I want to let you know the first guy who sets it up has a different process. For the subsequent developers its easy.
Everything in []
you would need to replace with your own project git URL’s, I gave you examples above how it would look if your project would be named xyzz.
// create the dir and get dev as your master local branch
mkdir [webroot]
cd [webroot]
git clone [dev_git_url] .
// cd to same directory with .git directory
// copy default .gitignore file to this directory
git add .gitignore
git commit -m "Add default gitignore"
// create the local branches
git branch stage
git branch prod
// make sure that the local branches track the remotes, environments that they need to
git remote add -t master stage [stage_git_url]
git remote add -t master prod [prod_git_url]
git config push.default upstream
git push
git push stage master
git push prod master
git branch -u stage/master stage
git branch -u prod/master prod
There you have it, now you have.
- master -tracking – Development
- stage- tracking – Staging
- prod – tracking – Production
Now any other developer that comes after you and wants to set it up on their own machines they need to do the following
mkdir [webroot]
cd [webroot]
git clone [dev_git_url] .
git branch stage
git branch prod
git remote add -t master stage [stage_git_url]
git remote add -t master prod [prod_git_url]
git config push.default upstream
git fetch stage
git fetch prod
git branch -u stage/master stage
git branch -u prod/master prod
You are free as free can be and implement the workflow we just described above.
Now add the initial code
Add the WordPress installation since it’s not added by default by WP engine.
To do that all you need to do is
- go back to WP engine to the environment
- create a fresh backup of the site
- download the backup and add it to your webroot folder
- checkout your local master branch
- git add, commit and push up to Development
- merge local master master to stage branch and send it up to Staging
- merge local master master to prod branch and send it up to Production
If you want to manage your local WordPress installation with WP CLI then check out my post about common WP CLI commands.
There you go you have everything in sync. WordPress core git ignored. So you don’t override WP engine updates and you are at complete liberty to chose you own workflow.
I hope this helps,
Lehel
How would you manage different features needing to be staged all at once but being deployed at different times? On top of different developers needing to work on the same features? In WPE, it doesn’t seem like we can push local feature branches for other devs to pull and continue to work on.