Syndeploy diagram

This project is not covered by Drupal’s security advisory policy.

Let's say that you want to deploy content from your staging site to production, or more generally, from one site to another (or multiple) sites. You could use Deployment, but what if you prefer a pull model over a push model? Then Syndeploy is for you. Changes are published via a feed, and then other sites can slurp them in. The slurping portion is to be handled by a corresponding Feeds processor plug-in.

This is essentially a glue module between several modules with pre-set defaults.

  1. A CCK content type is created to house a log entry for each content change.
  2. All change events are grouped together in a Rules rule set.
  3. Each rule, when triggered, fires a defined action that adds a log entry with a unique sequential identifier (thanks to the Serial Field module).
  4. A view is created with Views to combine all of the log entries.
  5. The view is then presented as a feed. (The details of this haven't been worked out yet. Please see #1239990: Determine the best method for providing the feed for details.)

Notes:

  • Using one of the activity logging / recent changes / audit trail modules was considered, but these seemed somewhat heavy and/or aren't using CCK. Why create Views hooks when you don't have to? CCK does this for us. Also, the schema can be changed directly from the UI. See Replacing the Activity module with Rules? for a bit of discussion on this.
  • Each consuming site needs to be kept in a consistent state, and we need to know how far along it is with respect to updates at a specific moment in time. To do so, we need some marker on each destination, an update ID, to tell us which state we're in. In addition, before applying new updates, we can compare each new update ID, and make sure that we've applied the previous one. This will ensure that we haven't missed any updates. If we have, a notification can be sent. So what really is an update ID? If we generate a record for each update on the source, its key will be unique, and can be used as an update ID. This ID can correspond with markers on each destination. So for example, if a particular consumer has update 37 (i.e. is marked with update ID 37), we'll know that this particular site has applied all of the updates up to and including the 37th one. And, we can see exactly what these are with the change log, the view of all change records.
  • Instead of placing huge amounts of content in the feed, there will simply be a pointer to the content/revision. The other side can then grab the new content with something like a Transport call in the Feeds processor.

Dependencies

Supported Rules events

When will there be a release?

The only item left to get an initial beta release out the door is #1239990: Determine the best method for providing the feed. If anyone out there can contribute to this issue, it'll get resolved quicker! :)

Supporting organizations: 
Drupal 6 architecture and development

Project information

Releases