The main goal was to standardize the workflow, environments, and deployment of dozens of our sites so both frontend and backend teams could work in tandem as requirements got increasingly complex.
One approach I took that differs from YeoPress & others was to abstract away most of the boilerplate (provisioning, deployment, wp-config nuances) away, so that as features are added & bugs are fixed, a simple `bower update` would resolve most of the problems, rather than having to re-generate the scaffolding.
I've really enjoyed working on it, and it has helped out the team immensely, so I hope open-sourcing it can help others using WordPress that have yet to benefit from Vagrant and other tools.
WP-CLI has been a huge time saver for me.. Use it on dev and production environments
I recently revisited the Roots theme and have been using it on all projects.
About to try Genesis out. I've been having trouble keeping track of dev/production DB's so I'm hoping this will help solve this problem
What I've been building instead is likening WordPress development to our other PHP/Node applications, where changing themes, installing plugins, and migrating data is done first locally, prepped for migration (either via a script, or just just deploying the entire DB back out), then released alongside other PRs.
Regarding Roots, I'm impressed with it, but decided to leave Roots, _s, and other themes/frameworks out by default, since the community is largely fragmented (us as well) regarding which is best.
The problem I'm solving next is the automated compilation of assets that's generally handled via Assetic, CodeKit, and other tools, but isn't part of the standard WP workflow.
So, we've already had Capistrano to help deploy lots of PHP apps, so this fit in quite nicely.
Ansible was a last-minute change from our Bash provisioning scripts. All in all, I'm very impressed with it, and it just simplified the crap out of the Bash scripts :D
I will be removing Capistrano as a dependency and either use (1) Ansible or (2) use an NPM module to just run the ~10 SSH commands needed for deployment.
$ cd provisioning
$ ansible-playbook provision -i local
$ ansible-playbook provision -i staging
$ ansible-playbook provision -i production
Granted, I've only been using Ansible for about a week, but it is definitely better than the bash scripts used before :)
As a heads up, here's how we currently use it:
1. We run `yo genesis-wordpress` on our existing project, and adjust to make sure we can `vagrant up` to work on it locally, then PR it down to `master`.
2. We have an existing server running on a shared machine ("old").
3. We run `cap old genesis:down` to download the old DB & files.
4. We create 2 new servers: "staging" on our company cloud, and "production" on Rackspace Cloud (NOT Chicago datacenter!) or AWS, then run `cap staging genesis:provision` and `cap production genesis:provision` to install the LAMP + Varnish stack.
5. Then, we send out `master` via `cap staging deploy` and `cap production deploy`.
6. Finally, we complete our migration with `cap staging genesis:up` and `cap production genesis:up`.
I don't know how many other people are migrating and destroy/creating sites like we are (when we significantly change our PHP/Varnish setup, we just move cloud servers), so it may be worth creating a couple videos or screenshot guides showing this off.
Being able to `cap old genesis:down` and `cap production genesis:up` to migrate machines is pretty awesome to me.
Let's make a science out of running something simple as a Wordpress that runs out of the box everywhere where PHP/MySQL is available.
WordPress is simple, yes, but a distributed team workflow with complex tools with WordPress is extremely difficult without these tools.
Here are the problems we've had without these tools:
- Our large WordPress sites existed on the single, live server. Installing plugins, uploading themes, fixing bugs, etc. always carried a huge risk, especially when something breaks but you wouldn't know until caching cleared.
- Every developer (out of a team of ~12), to work on the site, had their own LAMP/MAMP setup, some using WordPressMU, none using Vagrant, and many struggling to get a copy of the database & import it (which is difficult for a lot of WP devs).
- Because of the complexity in setting up & deployment, building semi-complex applications on top of WP was incredibly difficult, mainly because of lack of consistency between environments
- The staging environments that we did have were still out of date, and had a different .htaccess with basic auth for (pseudo) privacy. This got modified, erased, or erroneously "deployed" to production countless times. Not to mention issues with Google indexing a preview server for our distributed team.
Now this "overtooling" should make a lot more sense :)
For example, migrating a site between two servers can now be done by any member of the tech team with a couple of commands, and without worry!
"Wordpress runs out of the box everywhere PHP/MySQL is available." So.. when devs work on multiple projects with different requirements, different configurations or even different versions, nevermind the mess of using the same database server for multiple projects or of splitting one LAMP stack.
It just works.. until it doesn't, and then you need those "overtools".
That's what I call "overtooling". Keep simple things simple and preserve complex toolchains for complex tasks and environments.
I develop static websites in vagrant boxes. Why? I don't want to have any spillover from my development env to the host env. I have no webserver running on the host env, only the system ruby installed, no homebrew, no php other than what came with the box, no database, nothing. Everything I do goes into a containerized env that I can just delete when I'm done. No version conflicts between multiple versions of the same database, no leftovers after cleanup. Once you started working with vagrant boxes and have an appropriate workflow it's just less hassle to spin up a box than not.