Feature #118
Create a vagrant development environment to facilitate install profile dev
| Status: | New | Start date: | 12/19/2011 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | - | |||
| Target version: | - |
Description
Developing an install profile can be tedious if you're not used to continuously testing it. A vagrant env can be used to make setup as simple as "PROJECT=profilename vagrant up"
Should consider how guard might be used to re-run site-install on specific conditions (monitor features dir?), comparable to this methodology:
https://github.com/jedi4ever/vagrant-guard-demo
should consider giving the option to provision with chef_server and restricted validator client key, as this can phone home at regular intervals and update VM accordingly. This is perhaps more advantageous than pestering devs to vagrant destroy/up on a daily basis to keep up with infra changes, as chef-client runs in the background and tends to fail silently (leaving VM in a useable state). failed chef-runs can be logged centrally and this body of info can be used to mitigate future problems.
Helpful technique: https://gist.github.com/1010660
History
Updated by Patrick Connolly over 1 year ago
Actually, I've been thinking on this a bit (especially considering some of the pain points we've had in developing install profiles within Myplanet), and I'm kinda excited by the prospects here...
I'm thinking on how to script things so that only the install profile needs to be in a vagrant shared dir. On the vagrant machine itself, it's not actually in the drupal docroot, but is symlinked in as part of the "guard" script (see the linked article above). So we have guard "watching" the install profile (or certain dirs within) for changes, and on change, it starts through a process of running drush make and site-install in the background in a non-intrusive way -- so you can keep viewing your working site right up until it symlinks the install profile into place and imports the db (site-installed in a tmp db?)
Need to work out the specifics, but there's some cool opportunity to be continuously testing the install process, with as little pain to the developer as possible. Definitely some things to think through, but it's potentially an exciting direction as far as I'm concerned.
EDIT: I'd like to retract my previous excitement, as it's not really an effective way to work. Just need to focus on making it dead simple to build from a local install profile without losing the ability to push (as happens when you include local sources in a makefile). Rebuilding on every change is a bit trigger happy, as walkah made me realize