deployment

Overview: Transformations is an API for creating and executing data transformation pipelines, enabling higher-level modules to build stuff like Yahoo! Pipes or targeted import/export interfaces on top of it. The purpose of this project is to improve and build upon Transformations so that it not only provides a base framework but also satisfies a larger number of end-user needs, for example an AJAXified user interface.

Description:

Transformations was born out of the desire for a solution that can map any kind of structured data to any kind of other data, such as importing CSV or more complex XML files into Drupal nodes (with field mappings, obviously), exporting the data to the same files, or, if you will, providing an online converter that converts any RSS feed into Atom for example.

When performing such a large-scale transformation, some elements of the source data will likely need to be transformed on a smaller-scale level, e.g. you might need to convert a Unix timestamp into ISO date format at some point, or remove commas from a number string ("1,099.90") to conform to the target format, or perform string replacements on a given string field. At times, you might even need a combination of those transformations, or reference some other entity to construct the desired output data.

In order to do that kind of stuff, a simple mapping screen is not flexible enough, or would require lots of custom code to handle the more specific tasks. Transformations tries to solve that problem by splitting individual data transformation tasks into individual "operations" that can be chained into a larger transformation pipeline.

All this import/export malarky is actually part of a problem I identified many years ago, while writing FAPI.

FAPI in it's current state was always meant to be the first phase in a much larger project to fix a lot of the inherent design problems we have been bumping heads against now.

If the code looks 'non-drupal like' to you, keep in mind when this presentation was done, FAPI itself was new, and such sweeping changes still had an opportunity of being taken seriously. Unfortunately I suffered from burnout shortly afterwards, and extracted myself from doing serious core development.

FAPI3 - AKA Data API presentation

Read below for some comments on this :

Based on the discussions we had at DrupalCon, I've written up the beginnings of an API with a standardized set of hooks and some functions.

The details of how, for instance, the block module would save an object to disc might start through using the not-so-desirable form API, due to lack of another option. In the future, however, this could be changed using a more optimal method.

Also included is a generalized function to fetch set of default objects that are embedded in PHP (like views module or context module implement).

Discussion is encouraged. :-)

io.module

A number of solutions are springing up for deploying site configuration (spaces, patterns, etc). And solutions are starting to spring up around deployment of custom sites as well - the Aegir project and the Domains module both provide tools for pushing out multiple sites on a single infrastructure.

Hi folks,

it seems this group stalled a little bit, so lets try to give it some activity :-) I was wondering if this group has already collected some best practices around Drupal deployment and change management. So far, I have only found best practices for managing the source code of a drupal site, but I have not found anything how to transport configuration changes (done in the DB) from a devel environment to a production environment. As far as I can see there are no stable modules or scripts for that, at least not for D6. Any ideas where to look?

Regards,

Sebastian

I've uploaded the slides for my presentation on staging & deployment from this weekend.

http://heyrocker.com/drupal/content/drupalcamp-vancouver-staging-deploym...

Thanks so much to all the dcv08 organizers, and to everyone who came to my talk. It was really great and I look forward to further discussions!

See some of you at DrupalCamp Seattle!

I have been working on a framework that attempts to address some of the issues of deploying code and data in Drupal. It is outlined here:

http://heyrocker.com/drupal/content/deployment-and-change-management-fra...

I'd love to hear people's thoughts on this.

Is anyone interesting in having a brainstorming session on deployment and change/build management at Drupalcon Boston? This could either be an officially submitted proposal with an open agenda, or an unofficial get together in a side room at the conference center. It seems like a lot of us are struggling with enterprise-level deployment issues, and getting a bunch of smart and interested people in a room talking about their own solutions and brainstorming new ones would be useful for everyone. We all have our own ways of handling it and I'd love to hear other people's ideas.

http://www.bryght.com/blog/roland-tanglao/10-minutes-on-drupal-deploymen... has an excerpt from a really great discussion that ensued at DrupalCampLA during Firebright's dissertation on how hard it really is to properly upgrade the featureset on a Drupal site that's live and active.