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