[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