[development] Solving the dev->staging->live problem
Adrian Rossouw
adrian at bryght.com
Sun Aug 10 08:15:32 UTC 2008
On 10 Aug 2008, at 9:18 AM, Greg Dunlap wrote:
>
> This whole problem would be much simpler if every "thing" had a
> GUID. Get that in place, and building a system to do deployment in
> the way described above actually becomes a realistic proposition. As
> Sam implied I've been conceptualizing a solution based on this
> premise, but its been hard finding time to really work on it.
> Hopefully soon.
We could create an object table pretty simply, and just keep that
maintained, with the object type, object area (ie: production,
staging, etc)
and reference id. And could then just write drivers for each of the
object types.
Most of the 'drivers' would be really simple, ie; just wrapping
node_load and node_save or drupal_execute.
We could make it a lot simpler to support the object table by writing
a very simple fapi submit handler that gets added onto forms that
need to be indexed in the oid table :
$form['#submit']['drupal_object_register'] = array('node', 'nid',
'area'); // just tells it to use $form_values['nid'] and
$form_values['area'] when sticking it in the table.
We would also be able to handle versioning, although the idea of
tracking node revisions like this on a busy site with
revision tracking could get difficult. Add a datestamp on there, and
you could have the proper order to import objects too.
More information about the development
mailing list