[development] The right way to manage Drupal webiste development

[Michel Levy-Provençal]

Another idea we had today about this question... This is a chalkboard
solution. An idea... Something that has to be simplified and tested.
We gonna continue the reflexion and try to implement  the solution we
have found after... If somebody has any idea to simplify the process,
you are welcome...

_______________________________________________________________________

Imagine we have 3 instances:
- Production site
- Staging site
- Integration site

All the php code is commited by the different developpers on the
Integration site.
Every modification of the configuration (blocks, menus, views, ...)
are made on the integration server using the Drupal GUI.

For each version of the site, we use a special ID suffix for each
record in the database.
In the folowing example :
- the Production website is in V0 and the Production DB is using
0000xxxxxx ids.
- the Integration website is in V1 and the Integration DB is using
0001xxxxxx ids.

while(0) {

1st Step: "Production to Staging synchro":
The Staging DB is configured to be a slave of the Production DB to
allow a synchronisation Production->Staging.

2nd step: "Integration to Staging synchro":
We transfer the Integration php code to the Staging website.
We change the configuration of the Staging DB: the Staging DB is now
configured to be the slave of the Integration DB to allow a
synchronisation Integration->Staging.
Using suffixed ids allow us to limit conflicts between Integration and
Production.
At this step each new element "created" in the Integration cannot
conflict with the elements from the Production.

3rd Step: "Staging period"
The Staging DB is configured (another time) as slave of the Production
DB. This allow us to tests the Staging as a real-time replication of
the Production with the specific functions of the Integration.
PROBLEM: At this step each update done on the Integration is lost....
The Production overides it. Only created elements are saved... (And
this has to be fixed!!!!)

4rd Step: "Go Live!"
When the website is correctly tested, we stop the Production website,
dump the staging and transfer code and datas from Staging to
Production.

5th Step and last step: "Update Integration Website"
We transfer code and datas from Production to Integration.

}


2007/8/17, Allie Micka <allie at pajunas.com>:
>
> > Michel Levy-Provençal wrote:
>
> >> 2/ When our sites will be online, we will need to continue the
> >> development. The only way we found to manage this is to lock param
> >> tables on the live instance. And when we'll want to update the live
> >> website, we'll have to :
> >>  - update the php code (thanks svn)
> >>  - and (this is quite touchy) update the param tables using a sql
> >> import....
>
> At Advantage Labs, we find it quite handy to create a custom module
> for each project.  Most Drupal developers probably do this anyway -
> for form_alter hooks, canned views, and other behavior overrides.
>
> We also log configuration changes in that module's .install file.
> There, we can put variable_set's, sql queries, node_type_save()'s,
> whatever we want.
>
> Deployment means:
>    A. committing the SVN changes (and updating the instance, if
> necessary)
>    B. running update.php
>
> This is certainly more time-intensive, but it pays off if you have
> concurrent development and/or any sort of staging/QA process.  You
> can consistently QA and commit independent changes
>
> FWIW, we (and all other Advantage Labs Drupal hosting customers) also
> use a custom SVN process for Drupal management, where each commit by
> a developer results in 3 steps:
>
>    1. A pre-commit hook that "svn commit"'s the production site's
> data (for file uploads, database, etc. changes)
>    2. The actual commit by the developer, provided step #1 results in
> no merge errors.
>    3. An "svn update" on the production server instance to sync up to
> the developer's changes.
>
> At that point, for the process you're describing, we'd run update.php
> to bring in the config changes.  Also, the developer can get a
> refreshed db dump that includes more of the production data and
> config changes.
>
>
>
>
>
>
> Allie Micka
> pajunas interactive, inc.
> http://www.pajunas.com
>
> scalable web hosting and open source strategies
>
>
>


-- 
Michel Lévy-Provençal
+336 23 93 60 16 | mikiane.com