Staging Drupal 8 31 09 1 3

Staging Drupal

Managing Your Project in Multiple
Environments

Introduction
• Chris Pliakas
– drupal.org: cpliakas
– Twitter: @cpliakas
• Michelle Lauer
– drupal.org: miche
– Twitter: @lauermichelle
• CommonPlaces e-Solutions, LLC
– Twitter: @CommonPlaces
– New Hampshire, United States

Why are we here
• Discuss the challenges with developing a site in
multiple environments
• Offer some solutions
• Goals of our process and tools used across multiple
environments
– Allow for seamless code integration (syncing)
– Increase efficiency of distributing database
changes
– Minimize downtime and errors while updating
the production site

Why Stage Drupal?
• Websites are becoming increasingly complex.
• Transition to traditional software development
cycle.
• Multiple engineers/designers working on the same
project.
• Proper staging avoids conflicts, separates
development from production.

Multiple Environments
• Proper staging requires development, QA, and
production locations.
• Each developer has a separate copy of the
application in an isolated location.
• Flow is like a pipeline, development → QA →
production.
• Drupal is portable
• How to stage Drupal?

Managing Code
With Source Control
• Source control is essential in the staging process.
• Manages changes to the code over time.
• We recommend a standard “tags, branches, trunk”
repository layout.
• We separate core code from project code.
• rsync -avC –delete –exclude=dir src/ dst

What Files Should Be Under
Source Control?
• Separate code from user generated content.
• Create “templates” for environment specific files.
• Store database snapshots?
• Update code frequently to prevent conflicts.
• Check production for modifications.

Porting the Database
• Database snapshot and files tied together
• Mysqldump, pg_dump, *MyAdmin applications,
contributed solutions.
• Restore database, clear cache.
• Multisite considerations.

Code Release Cycle
• Developers import snapshot, commit changes.
• Changes promoted to QA, tested thoroughly.
• Admin steps, adding content tested on QA.
• Code is tagged.
• Code updated on production, manual changes
made again.
• Alpha, beta, stable release cycles.

Automate Administrative
Tasks Through Code
• When
– Multiple sandboxes needing the same database
changes
– Phased approach to release features
• Why
– Easily share changes among sandboxes
– Seamlessly add functionality to an active site
– Version control

A Systematic Approach
• Step 1
– Take a database snapshot with Demonstration
Site module (drupal.org/project/demo)
• Step 2
– Write it down!
– Separate out by sub-projects.
– Be explicit and exact
– For example, installing “Reroute Email”

“Admin List” example
• ADMIN
– [reroute email]
• Enable Reroute Email module
(admin/build/modules)
• Configure Reroute Email
(admin/settings/reroute_email)
– dev@company.com

• Step 3 – Choice Time
– How long is your admin list?
– Would it be faster for you to write a script that
all developers can run in their sandboxes and
also can be used on production?
– What is the best use of time here?
– It really is a judgment call. The more you write
database update scripts, the faster you become.

• Benefits of writing an update script
– All changes can be accessed in version control
and more easily debugged
– Test your deployment process several times as
part of QA
– You write it once and use it in as many
environments as you need

The “Site Module”
• MYSITE.module.
• Site specific configurations: hook_form_alter() and
hook_nodeapi().
• Use hook_update_N() in MYSITE.install to make
database changes across many development
environments.
• This “site module” is NOT intended to live outside
of its site or be installed anywhere other than its
site.

The “Site Module”
• The correct way to work with an install file is that
for every update function, you amend the install
function so that newly installed modules behave
correctly.
• That being said, my recommendations for a
MYSITE.install file are to NOT be used for any other
module you create – just the “site module”.

MYSITE.install
• New update function to replicate our “Admin List”.
• Configurations saved in the {variable} table.
function mymodule_update_N() {
$ret = array();
module_rebuild_cache();
$mods = array('reroute_email');
drupal_install_modules($mods);
variable_set(REROUTE_EMAIL_ADDRESS,
'mymail@company.com'));
return $ret;
}

Use Drupal Functions
• Examples vs direct sql query
– variable_set();
– node_submit(); node_save();
• Less error prone
– Inserting or updating data
– Several tables at once
– Lock tables
– Serialize data
– Clear cache

MYSITE.install Examples
• 5 development sandboxes, a testing server and
production.
• 5 critical nodes that you need to add and that
must be in every environment.
• That would be 35 instances of manually creating a
node. How tedious! Especially when you can write
it once for everyone.

Start Building
• You have to do it manually in one sandbox first
• Install Node Export
– drupal.org/project/node_export
• Install Content Copy
– drupal.org/project/cck
• Create Content Types and Taxonomies.
• Link taxonomies to content types either via
taxonomy interface or as a CCK field
• Create nodes

Content Types
• Create a folder in your module called
“content_types”
• Create a file in that folder called “my_type.cck”
• Export the type (admin/content/types/export)
• Put the contents of this export into your new file.
– You don't need <?php

Content Types
$modulepath = drupal_get_path ('module',
'drupalconparis2009');
$cck_definition_file =
$modulepath."/content_types/my_type.cck";
$form_state['values']['type_name'] = '<create>';
$form_state['values']['macro'] =
file_get_contents($cck_definition_file);
include_once(drupal_get_path('module',
'node') .'/content_types.inc');
include_once(drupal_get_path('module',
'content_copy')
.'/content_copy.module');
drupal_execute("content_copy_import_form",
$form_state);
content_clear_type_cache();

Vocabulary
$voc = array();
$voc['name'] = 'shuswi';
$voc['description'] = '';
$voc['nodes'] = array('page'=>'page',
'story'=>'story');
$voc['multiple'] = 1;
$voc['required'] = 0;
$voc['relations'] = 1;
$voc['hierarchy'] = 1;
$voc['weight'] = 0;
taxonomy_save_vocabulary($voc);

Terms
$vid = db_result(db_query("SELECT vid FROM
{vocabulary} WHERE name = '%s'", 'shuswi'));
$shuswi[] = 'bipagi';
$shuswi[] = 'jiphobre';
$shuswi[] = 'slid';
foreach ($shuswi as $k=>$v) {
$term = array();
$term['vid'] = $vid;
$term['name'] = $v;
$term['description'] = "";
$term['weight'] = 0;
taxonomy_save_term($term);
}

Exporting Nodes
• Create a folder in your module called “nodes”
• Create a file in it called nodes_20090904.inc
• Go to Administer Content (admin/content/node)
• Check the nodes you want to export
• Select “Export” from the bulk operation dropdown
– This returns an array of your node content
• Paste this code in your file
– You don't need <?php

Importing Nodes
//content arrays
$modulepath = drupal_get_path ('module','drupalconparis2009');
$nodes_file = $modulepath. "/nodes/nodes_20090904.inc";
eval('$nodes = '.file_get_contents($nodes_file).';');
//save nodes
foreach ($nodes as $node_array) {
unset($node_array['nid']);
unset($node_array['vid']);
unset($node_array['#_export_node_encode_object']);
unset($node_array['menu']);
foreach($node_array['taxonomy'] as $term) {
$term = (object)$term;
}
$node_object = node_submit($node_array);
node_save($node_object);
}

Export Views
• Version control because they are no longer in the
database
• Facilitates multiple sandboxes being in sync
• Create a folder in your site module called ‘views’
• Enable Views Export
• Export each view individually, create a file called
myview_name.inc
<?php
//your exported code here
$views[$view->name] = $view;

Views in Code – Site Module
function mymodule_views_api() {
return array(
'api' => 2,
'path' => drupal_get_path('module',mymodule) .
'/views/*.inc',
);
}
function mymodule_views_default_views() {
$path = './'. drupal_get_path('module',mymodule)
'/views/*.inc';
foreach (glob($path) as $views_filename) {
require_once($views_filename);
}
return $views;
}

Register Your New Views
• Clear views cache (admin/build/views/tools)
– This one tells the site that you have views in
code as well – now your previously placed views
generated blocks won’t get confused.
• “Revert” all the views that you just saved into
code. This will remove them from the database.
• Clear views cache again
– This one ensures that your site is only looking
for the views in code.

Permissions
• Permissions API
– drupal.org/project/permissions_api
• After all modules have been installed so you know
the names of all permissions and roles
$permissions = array(
'create mytype content',
'edit own mytype content',
'delete own mytype content',
);
permissions_grant_permissions('authenticated user',
$permissions);

Testing Your Install Script
• Take another database snapshot
• Reload the fresh database copy you took before
you started (without all those administrative
changes)
• Run your update script – mysite.com/update.php
• In the dropdown of your site module, select the N
of your script

Testing Your Install Script
• If there are errors
– Debug them and make changes
– Reset your database (admin/build/demo/reset)
– Run update.php again
• Make sure your configurations, taxonomies,
content all look as expected.
• When your team syncs their code and runs
update.php, they will now have a slew of database
changes instantly!

Recap
• Sometimes takes longer to write and test (and
reload DB) than to just email a list of admin steps
to your development team and repeat on
production.
• Remember, to be officially correct, all updates
should go also go in the install function. That way
the module can stand on its own.
• CCK types must be in separate file

Recap
• Must add bottom line to exported view in
mymodule/views/myview.inc
– $views[$view->name] = $view;
• Need two Views functions in your module
• Must unset the nid & vid on a node import because
node_save looks for an those to determine if it is
performing and update or insert
• If you get timeout errors, separate your updates
into several functions

Drupal Tools
• Devel: Generate: drupal.org/project/devel
• Demonstration Site: drupal.org/project/demo
• Node Export: drupal.org/project/node_export
• Permissions API:
drupal.org/project/permissions_api
• Views Export: drupal.org/project/views
• CCK: Content Copy: drupal.org/project/cck
• Drush: drupal.org/project/drush

More Options
• Blocks: Follow similar methodology as Content
Types by using the form function
– block_add_block_form
• drupal.org/project/variable_dump
• drupal.org/project/exportables
• drupal.org/project/transformations
• drupal.org/project/migrate
• drupal.org/project/deploy
• drupal.org/project/autopilot
• drupal.org/project/features

Questions & Answers
• Download this presentation
– www.CommonPlaces.com/Resources
• Follow the presenters on Twitter
– Chris: @CPliakas
– Michelle: @LauerMichelle
– CommonPlaces: @CommonPlaces

Staging Drupal 8 31 09 1 3

Recommended

More Related Content

What's hot (20)

Viewers also liked (17)

Similar to Staging Drupal 8 31 09 1 3 (20)

More from Drupalcon Paris (16)

Staging Drupal 8 31 09 1 3