By TamboWeb on

Hello All, I am looking for some comments/advise from the community. Please read on....

My workflow so far is to develop on my local box, then test, and deploy to the production site or live server. This process is straight forward and can be easily done with the first release iteration or initial release. However it can be problematic if a second production iteration is planned or if collaboration from multiple locations is expected.

Once the production site is "Live", it receives input from site visitors, content editors, and site owner input.

Developing a second iteration release to the production site without service interruption seems to be a monumental task of duplicate labor. Changes done on the development site need to be duplicated on the live site. Here is an example:

Production site 1st release: database receives comments, content, etc.

At the same time, the 2nd iteration development site database: receives new configuration settings, perhaps new content, etc.

The issue here is how to release the 2nd iteration changes without loosing the database changes of the 1st iteration release up to the new release date.

Placing the 1st iteration production site in maintenance mode while developing the 2nd iteration is not the best solution. as this may take anywhere from a couple of hours to several weeks.

Any thoughts? Thanks.

Sandro.

Edited by: VM; Moved to appropriate forum

⋅ Categories: Drupal 6.x

Comments

vm’s picture

vm commented

http://drupal.org/project/deploy

TamboWeb’s picture

TamboWeb commented

It looks promising, I will investigate. Thanks for the link.

So far my process has been to develop, dump a sql file, upload via FTP or SVN and load the new sql into the live server.

I am trying to figure out the best scenario to work with a client. Where the client will be testing the site, as they also get trained. Then the client will also input content as I implement additional functionality. Note these are two parallel processes. At some point, these two processes will have to merge into a content /configuration freeze and commit to a pre-release stage for final testing prior to deployment.

Things will get more complicated if we go further with an existing live server. Then you have 3 parallel processes. Live server, client input and development input.

So far the only solution that comes to mind without relying on a module would be to plan on releasing small changes often instead of one large release change.

Best regards, comments welcome.

Sandro.

ramirez.gerardo’s picture

ramirez.gerardo commented

You should also look into drush. The project page is located at http://drupal.org/project/drush.

this will help you upgrade the drupal code and allow you to set up a secure method when it comes to pushing your content to the production server.

Check out this thread; which the feature is now rolled into the latest version of drush: http://drupal.org/node/460924

dman’s picture

dman commented

Yes, small and often is the only small-scale way to go. Pity that fails when waiting for sign-off from clients etc :-)
Roll back a clone from live to dev as often as possible, so you are not too far out.

It comes down to recording the admin/UI changes you make on your dev site, and re-doing them on live once you are done. Not optimal, but it's actually a good learning process. There are tools like macro.module that may help, but are probably more trouble than it's worth.

For more industrial-strength deployments (and better testing) I now code my significant changes into patterns.module and upload and run them. Good for testing (you can do it on a dry clone of the server repeatedly) and also helps long-term documentation and reference, and is a learning experience (I like learning)

But in general, there is a huge cross-over between 'configs' and 'content' in the Drupal DB. Some of it is insoluble - taxonomy term IDs - are they data or conf? I use them as both.
I've tried doing DB diffs and merges before now. That was madness :-}

.dan. is the New Zealand Drupal Developer working on Government Web Standards

TamboWeb’s picture

TamboWeb commented

Hi all, Thanks for the comments.

I have not found any issues dealing with revision changes to core, module/theme or attached files changes.
The challenge comes in when trying to keep the database current.

During the initial development and first release this is a simple SQL Dump with an FTP transfer.

Now that I am working with more complex scenarios with multiple contributors and additional live releases. I am trying to establish a robust procedure for the release process.

It seems that such a procedure would require a series of differential database updates at various stages to facilitate the task of going from Live->Dev->Test->Staging->Live.

I found a couple of tools that may be useful: SQLyog and MySQLdiff (found in Drupal Problem Solutions in Database Migration from Development to Live Sites

Have anyone used the above mentioned tools? Would like to hear any comments about them.

I am working on a release procedure chart and would be wiling to share here if anyone is interested. Just let me know.

Thanks,
Sandro.

jp2020’s picture

jp2020 commented

There is Features, Drush, etc., and I am thinking along the ways of Sandro Live->Dev->Test->Staging->Live. Now that almost a whole year has gone by, is there a better solution for this?
Thanks,
JP

mcfilms’s picture

mcfilms commented

But I'm subscribing.

A list of some of the Drupal sites I have designed and/or developed can be viewed at motioncity.com

dddbbb’s picture

dddbbb commented

what he said...

f m d’s picture

f m d commented

subscribing!