Yeoman Generator for WordPress + Vagrant + Multi-env(github.com)
github.com
Yeoman Generator for WordPress + Vagrant + Multi-env
https://github.com/genesis/wordpress/
6 comments
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!
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!
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
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
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.
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.
Why do you need capistrano.
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.
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.
I was curious about that as well, especially given the latest cap news from the developer.
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.
Ansible is actually provisioning our 3 different deployment environments:
Granted, I've only been using Ansible for about a week, but it is definitely better than the bash scripts used before :)
$ 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 :)
The news came after we already had all of this working for the past month. Now there's even more reason to replace it :)
Wow! This is some seriously cool work. Very, very nicely done.
Thank you!
Thank you!
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.
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.
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.
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.
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.
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!
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!
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".
"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".
It's more for the integration with Vagrant than Wordpress itself.
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.
That's what I call "overtooling". Keep simple things simple and preserve complex toolchains for complex tasks and environments.
> 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.
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.
If you're deploying a personal blog, sure. What if you want to create a web service to automatically provision and deploy WP servers? There's a purpose for every 'overtooled' bundle of software, otherwise it wouldn't exist.
More for development......
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.