[development] Solving the dev->staging->live problem

[Sam Boyer]

On Sunday 10 August 2008 08:17:15 Victor Kane 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.
>
> Just a quick point on this: if every "thing" had a GUID (that is, a
> globally unique identifier (PHP's uniqid is sufficient if it the
> prefix parameter is invoked in order to identify the host machine's
> MAC, mayble butressed with an addional field based on an aleatory
> number, since otherwise duplicate timestamp based id's will be
> created), AND if every "thing" were serializable / unserializable (and
> here we mustn't forget certain encoding problems). Serializable: take
> an in memory object and turn it into a text object that can be stored
> in a file, version controlled, deployed via unserialization, etc.).
> Then you would have a realistic proposition.
>
> Certainly achievable for nodes, perhaps lots of other stuff, but I
> don't know if every "thing" in Drupal required for deployment, site
> merging, etc.
>
> Just wanted to extende thoughts in that direction.

So if I've missed this in your/others' thoughts Victor, please forgive me, 
but...why are we talking about serializing and unserializing data? As you 
pointed out in your first email:

> There is no straightforward way in Drupal to export and import a given
> content type's nodes.
> 
> No off-the-shelf, simple way of doing it.

I agree. So...why talk about it at all? Deploy uses that approach at present, 
but we needn't be wedded to it. It seems to me that the GUID-based system is 
the thinnest possible way of allowing Deploy to keep track of the fact that 
"Thing A" on server 1 is "Thing B" on server 2. Deploy's API shouldn't be 
aware of what the Things are - just that they need to be checked against each 
other. And then it's up to the module(s) that created (or altered) the Things 
to decide what data comprises them, how to check that data against each other 
on the servers, and then how to resolve differences. The two biggest problems 
with that are handling data changes which have dependency chains (node system 
type changes being the most obvious) and that it could potentially make for an 
API too complex for general consumption. But that seems less insurmountable to 
me than the import/export problem.

Unless I've missed something?

Sam


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.drupal.org/pipermail/development/attachments/20080810/93821d97/attachment.pgp