alternatief deployment scenario

Op de laatste DUG meeting (http://drupal.be/evenement/drushdug-drupal-user-group-meeting-over-drush) bleken er nog veel vraagstukken open te liggen wat deployment strategieën betreft waar drush nog geen sluitend antwoord op biedt.

Er werden een paar modules aangehaald die dit proces kunnen vergemakkelijken (zoals record_feature, fingerprint, settings bijhouden via ctools) die zich focussen op het migreren van development code en settings van een staging/development server naar een productieomgeving.

Wat als we het omgekeerde pad eens proberen te bewandelen:

  • Migratie van code + database(=content + settings) van PROD naar DEV - Ontwikkeling gebeurt op DEV, ondertussen wijzigen er geen settings op PROD, enkel content
  • Na ontwikkeling kan via de deploy module (http://drupal.org/project/deploy) de laatste content gemigreerd worden van PROD naar DEV (final testing met meest recente content)
  • Net voor de update naar productie doen we dan het volgende:
    • PROD site in maintenance mode
    • een laatste maal via de deploy module alle laatste content van PROD naar DEV migreren
    • de volledige database (=nieuwste content + dev settings) van DEV naar PROD migreren
    • de laatste code van DEV naar PROD
    • PROD uit maintenance mode

Dit zou perfect moeten werken voor nodes, node references, taxonomy, users, comments, files, ... kortom alles wat de deployment module ondersteunt.

De keerzijde van de medaille: alle nieuwe content die rechtstreeks (dus niet via nodeapi hook) in module specifieke tabellen wordt opgeslaan gaat verloren doorheen dit proces. Misschien dat dit met de juiste hooks wel in orde kan komen? 

Graag feedback!

Drupalversie: 
6.x
Auteur: 
gmork
Bookmark and Share

Drupal is een geregistreerd merk van Dries Buytaert. | Powered by Pantheon.

Drupal.be/Drupal.nl is de website van de Nederlandstalige Drupalgemeenschap.