drush recipes automatic upgrade reading

proposed structure

{timestamp}.drecipe

side note: make a simple update recipe that doesn't do the RR / cron / cache stuff

(whatever folder you want below)

/drush/upgrades
--/sites
----UNIXSTAMP.drecipe
--/courses-all
----UNIXSTAMP.drecipe
--/interact-all
----UNIXSTAMP.drecipe

Examples to call above:
drush @sites dr-up /drush/upgrades
looks for /drush/upgrades/sites to match the target in question. Cooks all recipes in this directory, per site, after reading off of the site what the last upgrade script was that was applied.

drush @sites dr-up /drush/upgrades/sites
looks in drush @sites dr-up /drush/upgrades/sites/sites (sees it doesn't exist) just uses /drush/upgrades/sites

drush @courses-all dr-up /drush/upgrades
Same as above

drush @interact-all dr-up /drush/upgrades/sites --ignore-target-dir
This won't work cause interact-all can't be found in this directory unless we supply an option ignore-target-dir which means that we are not looking for /drush/upgrades/sites/interact-all and we are instead saying "run everything in this folder

drush @interact-all dr-up /drush --spider
Look in every folder in /drush for the target in question (which means /drush/coolstuff/interact-all would match as well as /drush/upgrades/interact-all)

/drush/upgrades
--/7.x
----/courses
------/courses-all
--------UNIXSTAMP.drecipe
------/art010
--------UNIXSTAMP.drecipe
----/interact
------/interact-all
--------UNIXSTAMP.drecipe

drush @courses.art010 dr-up /drush/upgrades/7.x --spider
Look in every folder in /drush/upgrades/7.x for the target in question. It finds a match in /drush/upgrades/7.x/courses/art010 which means it cares about timestamps in this directory to run

drush @courses.art010 dr-up /drush/upgrades/7.x --spider --ignore-target-dir
Find everything in the /drush/upgrades/7.x directory, IGNORING THE TARGET WE ARE LOOKING FOR, AAAAND spider. So, we find EVERY timestamp inside the /drush/upgrades/7.x directory across other directories (all 3 drecipes), compare against the timestamp in the site's variable, then run them in order.



These options and abilities allow you to structure in whatever way makes sense for your organization / project.

Multidev:
/upgrades
--/dev1
----TIMESTAMP1.drecipe
----TIMESTAMP2.drecipe
----TIMESTAMP3.drecipe
--/dev2
----TIMESTAMP4.drecipe
----TIMESTAMP5.drecipe
----TIMESTAMP6.drecipe
--/stage
----TIMESTAMP1.drecipe
----TIMESTAMP4.drecipe
----TIMESTAMP6.drecipe
--/prod
----TIMESTAMP1.drecipe
----TIMESTAMP4.drecipe
----TIMESTAMP6.drecipe

Run the commands above against dev, they work, coworker tests stuff on dev2, merge the upgrade routines together based on timestamp and test on stage? works there? run them on prod.

drush @dev1 dr-up /upgrades
drush @dev2 dr-up /upgrades
drush @stage dr-up /upgrades
if that worked...
drush @prod dr-up /upgrades

Now, work this in with madlibs... hehe.
drush [target] dr-up [location]
drush cook our-custom-upgrades --y --mlt-target=@dev --mlt-location=/upgrades

If the assertion spec gets worked in / the tokenized conditional statements, we could have 1 command apply our migration / pull down routines from prod to dev THEN apply the upgrade routines to get it back to a certain point.

related d.o. issue https://www.drupal.org/node/2340713