Best Practices for development & deployment

More structured, more productive, more done!

Somedutta Ghosh

Best practices in -

★ Drupal - security, structuring, custom coding, etc.

★ Git - Version control tool

★ Deployment method

★ Drush

Drupal Best Practices● NEVER. HACK. CORE.

Drupal Best Practices● No development on live.

● Disable development modules on production/live environment.○ views_ui○ field_ui○ devel

● All drupal level logging should be on only on non-production environments; only server level logging on live.○ dblog off - syslog on

Drupal Best Practices● Preferable to use server level logging instead of

drupal logging, as this will remove unnecessary database writing for the application.

● Choosing Syslog over Drupal watchdog

● Enable logging of slow queries in mysql.

Drupal Best Practices● Files and directory ownership and permissions,

○ group should include web server, and ○ only owner and group should be given permissions.

Drupal Best Practices● JS, CSS should not be present in database (css inside the element

can be present as we could have with wysiwyg text editor)○ no jss/css in node content○ no jss/css in block content

<script type="text/javascript" > jQuery(window).load(function() { jQuery('.pics').cycle({ fx: 'scrollLeft', next: '#right', delay: 2000 , }); });</script>

<style> .pics { width: 100%; margin: 10px; }</style>

Writing Custom Code● Add helpful documentations for

all modules. Always add a README.txt file in all custom modules.

● Add documentation for functions and inline comments for understanding the code.

Writing Custom Code● Before writing custom, look for contrib.

● Make sure you use the extensive drupal API instead of writing custom functions/code.

● Use drupal database API for making db calls.

● Use drupal form API for creating forms.

● Use theme functions like theme_image, theme_links instead of writing raw html.

● To show any text always use the t() function.

● For creating links always use l() function instead of a tags.

Writing Custom Code● Try to avoid writing functionality related code in theme.

● Follow naming conventions for easier management.

● all features can be prepended by ‘feature_’

● all custom modules and theme can be prepended by the initials of the sitename. eg. for site ‘Alpha’ use ‘a_’ or ‘alpha_’

Modules - contrib and custom● Improve structuring - move modules to separate folders

under sites/all/modules/ depending on custom, contrib, features or modified.

Modules - contrib and custom● Often we need to apply patches or modify contrib

modules. In such a case,

○ create another folder under modules - patches○ store all applied patch inside this

○ keep a README.txt file in /patch folder to record patches applied, the module they were applied on and their purpose

○ when modifying modules, create a patch from them and treat those patches same as other patches

Make your modules Modular!● Separate functionalities should go into separate modules.● Use small functions, where each function performs a

specific part of a big functionality. Try making these functions as general as possible and use arguments instead of hardcoding, such that they can be used multiple times and with different data.

● For long and heavy operations, use batch process.

Custom modules● Use the theme layer for printing HTML. Use tpl files for

large amounts of HTML code. Small html code could go into non-tpm files like .module files.

● CSS/JS for specific pages should not be added on every page○ if adding css/js to every page through hook init move

them to theme’s info file○ add these files through page callbacks

Theme● PHP should be present in tpl files for either conditions or

printing variables; all calculations should be done in template.php file.

● CSS/JS should not be present in template.php; add them through files and included via theme’s info file.

Git Best PracticesEssential to use version control. The greatest plus points of git are - ● branching - multiple functionalities can be kept separate● distributed - multiple developers can work on the same

codebase at the same time, and git smoothly merges the code

● different versions of the same file - with extensive options of viewing log of changes, one can see when a file or a line of code was added

Git Best Practices● Keep individual functionalities in individual branches● When on a feature branch, merge with the base branch often

● Branch out from development branch for new functionality.● Branch out from master(production) branch for production bug

fixes.

Git Best Practices● Have intuitive branch names - eg. each

feature/functionality branch prepended with feat_ or each bugfix branch prepended with bugfix_

● production, stage, dev - different instances in the development tree - deploy a different branch on each instance - master, stage, dev respectively.

Git Best Practices● Commit early. Commit often.● Commit messages should be useful, insightful and

descriptive● Make a habit of git commit instead of git commit -m

“[message]”. This opens an editor where you can write a more descriptive commit message

● Set up a .gitignore file - to exclude configuration files that are server environment dependent and large binary files

● Do not add settings.php and files folder in git repository● After completing a feature from local to production, delete the

branch

Deployment Best Practices● 3 environments should be used - production, staging and

development.

● dev - any new code is first deployed and tested here. work from all developers will be tested here

● stage/test - the content will be same as the live instance and updated code from dev will be tested here

● production/live - it is the live instance. New code/functionality after passing tests on the stage environment, can be moved to live.

Deployment Best Practices● All changes should always go through dev and staging

before production so that the changes can be extensively tested.

● Version control tool should be used since it makes moving code between environments very easy and especially useful when multiple people are working on the same code.

● Use features and strongarm to move database changes between environments - reduces configuration times on different environments.

Drush - do less, get more● drush cc all - clear all cache

● drush dl [project_name] - download modules

● drush en -y [project_name] - enable modules

● drush dis -y [project_name] - disable modules

● drush pm-uninstall -y [project_name] - uninstalll modules

● drush pm-list - show list of modules with their status, enabled,

disabled, not installed

Drush - do less, get more● drush fl - to list all features and show their state, overridden or not

● drush fd [feature_name] - show overrides in feature; you will need module diff for using this command

● drush fu -y [feature_name] - updates the feature(db to code)● drush fr -y [feature_name] - reverts the feature(code to db)● creating feature using drush

○ drush fe [feature-name] [feature-component(s)] - export/create or update a feature with one or more components

○ drush fc - show a list of feature components that can be exported into features

Drush - do less, get more● drush updb - running update.php from drush

● drush cron - run cron from drush

● drush ws - show list of latest 10(default count, can be increased with

option in command) messages messages

● drush upwd - Reset the password for an user account that has the

given username(username to be specified in command)

● drush sqlq “[sql-query]” - run any db query from drush

● drush sql-dump - take a sql dump of the current site’s database

Drush - do less, get moreDrush alias -

● an alias is basically a short name for a drupal installation. It is a set

of options that collectively define that installation.

● its biggest advantage is super easy syncing with remote servers and

running drush commands on remote servers locally

Drush - do less, get more● create a drush alias file - sitename.alias.drushrc.php, eg alpha.alias.

drushrc.php● place it in either of -

○ ~/.drush○ sites/all/drush

● the simplest content of an alias file could be<?php $aliases[local] = array( 'root' => '/var/www/alpha' );

● now you can access your local environment for drush through - drush @alpha.local status

Drush - do less, get more● for adding a remote configuration, eg. dev on a remote server, add

following to above alias file$aliases[dev] = array( 'root' => '/home/alpha/public_html', 'remote-host' => 'alpha.dev.com', 'remote-user' => alpha',);

● if ssh requires password authentication, add this to alias config of the remote - 'ssh-options' => '-o PasswordAuthentication=yes' - this will prompt for password every time you use drush with the remote’s alias

Drush - do less, get more● we now have 2 aliases for the site alpha

* drush @alpha.local * drush @alpha.dev

● syncing local database with remote with single command○ drush sql-sync [source] [destination]○ drush sql-sync @alpha.dev@alpha.local

● syncing local files folder with remote with single command and drush alias○ drush rsync [source]:sites/default/files/ [destination]:

sites/default/files/○ drush rsync @alpha.dev:sites/default/files/ @alpha.local:

sites/default/files/

Drush - do less, get more

● drush help - list of drush commands and their use; drush help [command] gives more help information about a specific command