Yeoman Generator for WordPress + Vagrant + Multi-env

by ericclemmons • 13 years ago

47 22 13 years ago

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• 13 years ago

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!

ericclemmons8• 13 years ago

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• 13 years ago

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

ericclemmons8• 13 years ago

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.

greg5green• 13 years ago

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.

ericclemmons8• 13 years ago

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.

eksith• 13 years ago

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

Thank you!

kuebelreiter2• 13 years ago

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.

thejosh• 13 years ago

More for development......

lewispollard2• 13 years ago

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

kuebelreiter2• 13 years ago

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.

likeclockwork• 13 years ago

I think you're ignoring the usefulness of both being able to start a project immediately and being able to have a portable development environment.

"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".

ericclemmons8• 13 years ago

The entire Yeoman ecosystem will probably seem like "overtooling" then :)

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!

yeukhon2• 13 years ago

Why do you need capistrano.

interstitial• 13 years ago

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

yeukhon2• 13 years ago

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.

ericclemmons8• 13 years ago

The news came after we already had all of this working for the past month. Now there's even more reason to replace it :)

ericclemmons8• 13 years ago

Actually, it's there just because of legacy tools we had :)

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.

Yeoman Generator for WordPress + Vagrant + Multi-env

Related Stories