Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Drupal Workflow Concepts

3,773 views

Published on

Drupal Workflow Concepts Overview slides from the TriDUG Meetup on Feb 21. Used to introduce the open floor discussion on how people manage Dev -> Staging -> Production workflows.

Published in: Technology
  • Be the first to comment

Drupal Workflow Concepts

  1. 1. Drupal Workflow Concepts Some concepts needed for understanding Drupal Dev., Staging, and Production workflow needs
  2. 2. Site Lifecycles <ul><li>New Site design </li></ul><ul><ul><li>Functionality, Layout, Coding, Theming, Review, Rework, Deployment </li></ul></ul><ul><li>Site maintenance and updating </li></ul><ul><ul><li>Core/Module updates, add functionality, fix problems </li></ul></ul><ul><li>Site overhaul </li></ul><ul><ul><li>Functionality, Layout, Coding, Theming, Review, Rework, Content migration/ Deployment </li></ul></ul>
  3. 3. Development, Staging, & Production Sites <ul><li>Development Sites </li></ul><ul><ul><li>One or more sites used to develop code or themes that resemble the production (but not exactly match) </li></ul></ul><ul><li>Staging Site </li></ul><ul><ul><li>A site that closely resembles the production site with new items from the development sites integrated in. Used for testing, client approval, etc. </li></ul></ul><ul><li>Production Sites </li></ul><ul><ul><li>The “live” site </li></ul></ul>
  4. 4. Benefits of D-S-P Sites <ul><li>Allows multiple people to do site development </li></ul><ul><li>Supplies a “safety net” for updates </li></ul><ul><li>Changes can easily reviewed by key stakeholders before they are released to production </li></ul><ul><li>Supplies a safe environment to test or problem debug without affecting the real site </li></ul><ul><li>Encourages workflow methods that allow for roll back/change tracking </li></ul>
  5. 5. Disadvantages of D-S-P Sites <ul><li>Requires more effort than “just updating the production site” </li></ul><ul><li>Copying/Merging Drupal sites can be “painful” </li></ul><ul><li>Requires people to “play by the same rules” </li></ul><ul><li>Incorrectly “Cloned” staging sites could: </li></ul><ul><ul><li>accidentally use the same “schema/database” as the production site and cause MANY problems </li></ul></ul><ul><ul><li>send erroneous messages to your live site users </li></ul></ul>
  6. 6. Parts of a Drupal Site Settings.php <ul><li>Core </li></ul><ul><li>Modules </li></ul><ul><li>Themes </li></ul><ul><li>Images </li></ul><ul><li>Attachments </li></ul><ul><li>And the like </li></ul><ul><li>Variables </li></ul><ul><li>Node types </li></ul><ul><li>Block Layout </li></ul><ul><li>Views </li></ul><ul><li>And the like </li></ul><ul><li>Nodes </li></ul><ul><li>Comments </li></ul><ul><li>Users </li></ul><ul><li>And the like </li></ul>FILES DATA Code Content Settings Content
  7. 7. Basic File Cloning <ul><li>Code </li></ul><ul><ul><li>Ideally, should use a good version control system like GIT. But a set of zip/tar archives could work too. </li></ul></ul><ul><li>Content </li></ul><ul><ul><li>Can use version control but generally not a good idea. A set of zip/tar archives with a good transfer tool works. </li></ul></ul><ul><ul><li>Best practice is to only “pull” content files from production (unless initial deploy). </li></ul></ul><ul><li>General </li></ul><ul><ul><li>If possible, keep the same directory/file structure. </li></ul></ul><ul><ul><li>ALWAYS modify the settings.php to use the correct database </li></ul></ul>
  8. 8. Basic Database Cloning <ul><li>Create a backup using the Backup Migrate module </li></ul><ul><ul><li>Make sure ALL cache_* table content is excluded. </li></ul></ul><ul><li>Import via command line or SQL admin tool </li></ul><ul><li>Clear cache </li></ul><ul><li>Run update.php (in case modules updated/relocated) </li></ul><ul><li>Clean up settings, change user e-mails and the like. </li></ul>
  9. 9. Some Cloned Database “gotchas” <ul><li>Pending user notifications in the database tables get sent with cron runs. </li></ul><ul><li>Cloned users should have e-mails changed to prevent accidental messages. </li></ul><ul><li>If URL change, e.g. my.site.com/main -> my.site.com/stage, some embedded URLs might send you to the production site or not work. </li></ul><ul><li>Theme cache problems (clear cache via DRUSH if needed) </li></ul><ul><li>File paths may need to be reset in admin screens. </li></ul>
  10. 10. Questions / Open floor discussion This has covered the basic concepts but a lot of details about best practices, merging changes, and the like need discussion.

×