Drush instance

This project has been mothballed in favour of the great initiative to bring Drupal ever closer to Composer, and hence "off the island" of otherwise great tools like Drush Make. Check out the post-install hooks in the drupal-composer project above, if you want to script basically anything Drush Instance could do!

Site-alias-driven, drush-making of local development instances and live production instances. Building a fully working codebase instance should only ever require:

• A sites/default repository
• A Drush makefile (which could go in the above)
• A Drush site alias

All of these can be stored under version control, but you never need to store any of the d.o projects yourself, drastically reducing download sizes.

Rationale

Drush make only gets you so far in building a site: it builds exactly what's specified in the makefile but goes no further. What else does a local site build need? Well:

• A sites/default containing your instance's custom code
• Any local changes to your settings.php file
• A sites/files directory
• Uploaded assets in the files directory (possibly synced from live)
• Templates to use for e.g. vhost, crontab entries etc.
• Occasional odd hacks and tweaks to the codebase, difficult to carry out in an automated way

And if you want to redeploy your local instance, to clear out cruft or switch to a completely different branch of your makefile, then at least some of these need to be carried over from the previous deployment. Drush instance should understand all of this "post-make" procedure and help you implement it.

Related projects

• Drush make is as discussed great for kicking off a site build, but doesn't fill in all the gaps.
• Drush deploy is a great Capistrano-like framework for remote
  deployment of code and scripting of Drush tasks. Drush instance could be called by Drush deploy, and avoid you having to rewrite your own Drush deploy commands to replace the "package of functionality" that Drush instance provides.
• Aegir is intended for moving/replicating site instances within a server or from server to server. How you build the initial instance, and how you store it under version control, is still up to you: Drush instance is a good way of building it, that makes full use of existing technologies like Drush make and Drush site aliases.
• Drush rebuild is oriented at creating development environments as replicas of production environments: a site synchronization, codebase and database, followed by database-level customizations e.g. permissions changes. Drush instance is instead about building or rebuilding a codebase anywhere - development, staging or production - and is agnostic about any post-deployment fixes to the database.
• Drush fetcher is another project for setting up entire development environments: codebase, database and all sorts of post-build custom tweaks, like switching off securepages and switching on devel. The codebase fetch phase could in principle call Drush instance to do a lot of the heavy lifting.