extremely interesting

We had a discussion at DrupalCon about many of these topics. It seems many of us are trying to solve these issues, in many different ways.

There's a lot to like about your approach, but one problem I think of has to do with IDs. Let's say your task is to replace the site's front page. So you create a new node on your development box, say it ends up being node/42. Then you go to settings and make the site frontpage "node/42". When you run the deployment script on the production server, it creates an identical node, but the nid is different, say 1234; and the frontpage will become node/42, which will be the wrong page.

You may think that's easily solved with an alias or what have you, but the problem will occur when any drupal object refers to any other. For example the id of the user who created the node, a node reference field, even vocabularies and terms. In the latter case, your deployment script might create vocabulary with vid 42, then add 10 terms to it. Later the deployment script would create a new vocabulary that gets ID 123, then proceeds to add 10 terms to vocabulary 42, whatever that happens to be on the other server.

Reply

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options