
Yeoman Generator for WordPress + Vagrant + Multi-env - ericclemmons
https://github.com/genesis/wordpress/
======
ericclemmons
OP + author here. I just open-sourced the first of several starter-skeletons
my company uses (WordPress, AngularJS, React, ExpressJS, etc.).

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.

~~~
otisfunkmeyer
This looks totally amazing. Thank you for doing this and also for documenting
it so well! I had to spend a lot of extra time with other Vagrant/WP
integration concepts just because a lot of them were very poorly documented.
Cheers!

~~~
ericclemmons
Thanks! If you have any opinions, issues, or whatever (I just wrote the docs
today =/), open a ticket. I'm pretty active in my other open-source projects
and <3 trying new concepts & ideas!

------
sdnguyen90
I've been very happy with all the open sourced WordPress tools coming out..

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

~~~
ericclemmons
The last time I tried out WP-CLI was, admittedly, ~ year ago, where I believe
the limitation was that you administered the WordPress install on the same
machine it ran on, rather than administering via ansible, capistrano, or other
DevOps tools.

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.

------
yeukhon
Why do you need capistrano.

~~~
interstitial
I was curious about that as well, especially given the latest cap news from
the developer.

~~~
yeukhon
I was more interested in why use it alongside with ansible; does it need to be
multi-server automation? I thought it was just a toy server for development
purpose. ansible seems enough for that kind of job (if it just needs to be a
single server - and even for a few additional one that's adequate too.

~~~
ericclemmons
Ansible is actually provisioning our 3 different deployment environments:

    
    
        $ cd provisioning
        $ ansible-playbook provision -i local
        $ ansible-playbook provision -i staging
        $ ansible-playbook provision -i production
    

Running `cap {env} genesis:provision` pretty much just runs that script, but
has a fail-safe wrapper for the _first time_ you provision a new server,
because you will need to provide a username+password. After provisioning,
there's a "deploy" user with a private key used for SSH going forward.

Granted, I've only been using Ansible for about a week, but it is definitely
better than the bash scripts used before :)

------
eksith
Wow! This is some seriously cool work. Very, very nicely done.

Thank you!

------
greg5green
I'll have to try this out next time I work with on a new WP project. Don't do
it often enough to have my own workflow set.

~~~
ericclemmons
Tweet @ericclemmons or open an issue if you need some help.

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.

------
kuebelreiter
Nice example for the recent trend of "overtooling".

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.

~~~
lewispollard
It's more for the integration with Vagrant than Wordpress itself.

~~~
kuebelreiter
IMHO WP is not complex enough to have a necessity to develop with it in
Vagrant.

That's what I call "overtooling". Keep simple things simple and preserve
complex toolchains for complex tasks and environments.

~~~
Xylakant
> IMHO WP is not complex enough to have a necessity to develop with it in
> Vagrant.

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.

