Drush alias files gebruiken in teams

Blog

Binnen LimoenGroen maken we veel gebruik van Drush en Drush alias files. Voor wie nog niet weet waar ik het nu over heb, een korte introductie. Als je al weet wat drush is en wat drush alias files zijn dan klik je gelijk door naar de tip voor teams.

Wat is Drush?

De meeste Drupal ontwikkelaars gebruiken Drush (Drupal Shell) om hun processen te versnellen. Drush installeer je lokaal op je pc en die kan je vervolgens gebruiken om zaken die je normaliter via de Drupal interface regelt, te doen via de command-line (en dus sneller).

Enkele veelgebruikte drush commando’s:

  • drush cc all: legen van alle Drupal caches
  • drush fra: alle features terugzetten
  • drush upwd Baris –password=”test”: wachtwoord van account Baris instellen op ‘test’
  • drush sql-dump > dump.sql: export maken van de huidige database
  • drush sqlc < dump.sql: export terugzetten

Het is vrij eenvoudig om zelf eigen drush commando’s te maken, voor zaken die je in je eigen werkomgeving regelmatig doet. Veel community modules leveren ook commando’s voor drush (bijv drush search-api-index om je content te indexeren).

Wat zijn drush alias files?

In zogenaamde alias files beschrijf je de serverinformatie per site. Hierin staan de systeempaden, filesdirectories en usernames van elke omgeving van de betreffende site. Wij maken per website 1 alias file. Deze ziet er bijvoorbeeld zo uit:

Bestandsnaam: limoengroen.aliases.drushrc.php. Deze staat in mijn aliases folder binnen de Drush folder. Op Linux is dat ~/.drush/aliases

limoengroen.aliases.drushrc.php

$aliases['dev'] = array(
  'root' => '/Users/BarisW/Sites/limoengroen.nl',
  'uri' => 'dev.limoengroen.nl',
  'path-aliases' => array(
    '%dump' => '/tmp/dump-limoengroen.sql',
    '%files' => 'files',
   ),
);
 
$aliases['test'] = array(
  'root' => '/var/www/limoengroen-test/htdocs',
  'remote-host' => 'webserver1.limoengroen.nl',
  'remote-user' => 'username-test&rsquo;,
  'uri' => 'www-test.limoengroen.nl',
  'path-aliases' => array(
    '%dump' => '/tmp/dump-limoengroen.sql',
    '%files' => 'files',
   ),
);
 
$aliases['prod'] = array(
  'root' => '/var/www/limoengroen.nl-prod/htdocs',
  'remote-host' => 'webserver2.limoengroen.nl',
  'remote-user' => 'username-prod',
  'uri' => 'www.limoengroen.nl',
  'path-aliases' => array(
    '%dump' => '/tmp/dump-limoengroen.sql',
    '%files' => 'files',
   ),
);

Het voordeel van het gebruik van alias files is dat je nu eenvoudig alle drush commando’s ook externe servers kan uitvoeren. Voorwaarde is dan wel dat je SSH toegang hebt tot die omgeving en dat daar ook Drush is geinstalleerd. Wil je niet steeds je wachtwoord in willen typen, dan kan je natuurlijk ook je SSH key toevoegen op de externe server. 

Zo kan ik nu eenvoudig de caches clearen op productie door het volgende commando aan te roepen:

Caches legen op de productieomgeving

drush @limoengroen.prod cc all

Of, als ik de database van productie naar mijn lokale omgeving wil halen:

Productiedatabase kopieren naar de lokale omgeving

drush sql-sync @limoengroen.prod @limoengroen.dev

Ideaal! En eventueel kan sql-sync de data ook nog sanitizen (zodat alle passwords en mailadressen worden geobscured). Dit voorkomt dat ontwikkelaars gevoelige klantdata lokaal hebben staan.

Productiedatabase opschonen bij kopieren

drush sql-sync @limoengroen.prod @limoengroen.dev --sanitize

Drush alias files synchroniseren binnen teams

Erg handig, maar elke developer moest dan telkens de gegevens van de diverse omgevingen lokaal in de alias files zetten. De oplossing die we hiervoor bedacht hebben is simpel maar erg doeltreffend: Dropbox/SparkleShare of soortgelijk.

We hebben in Dropbox een folder gemaakt waar alle alias files in staan. De alias folder in ~/.drush/aliases hebben we gesymlinked naar die folder. Op die manier heeft elke teamlid altijd de juiste gegevens van de projectomgevingen. Ook kun je deze alias files gebruiken op je Continuous Integration omgevingen (zo gebruiken wij ze ook weer voor gautomatiseerd deployen middels Jenkins).

Daarvoor moesten we 1 ding aanpassen: in plaats van de ‘dev’ alias gebruiken we nu de namen van de medewerkers (omdat elke medewerker zijn lokale omgeving ergens anders heeft draaien). Dus in mijn geval is het nu dan:

Productiedatabase kopieren naar de lokale omgeving

drush sql-sync @limoengroen.prod @limoengroen.baris

Bonus-tip: alias file inherintance

Helemaal leuk wordt het als je gebruik gaat maken van inherintance. Zo hebben wij een localdev alias waar alle defaults instaan voor lokale omgevingen:

defaults.aliases.drushrc.php

$aliases['localdev'] = array(
  'target-command-specific' => array(
    'sql-sync' => array(
      'sanitize' => TRUE,
      'confirm-sanitizations' => TRUE,
      'no-ordered-dump' => TRUE,
      'no-cache' => TRUE,
      'enable' => array(
        'devel',
        'stage_file_proxy',
        'ds_ui',
        'fields_ui',
        'views_ui',
      ),
    ),
  ),
);

limoengroen.aliases.drushrc.php

$aliases['localdev'] = array(
  'parent' => '@defaults.localdev',
  'uri' => 'dev.limoengroen.nl',
  'path-aliases' => array(
    '%dump' => '/tmp/limoengroen-dump.sql',
    '%files' => 'files',
  ),
);
 
$aliases['baris'] = array(
  'parent' => '@limoengroen.localdev',
  'root' => '/Users/BarisW/Sites/limoengroen.nl',
);
 
$aliases['eric'] = array(
  'parent' => '@limoengroen.localdev',
  'root' => '/Users/EricM/Sites/dev.limoengroen.nl',
);

Deze setup zorgt ervoor dat bij elke sql-sync automatisch de data wordt gesanitized, en dat er een aantal developer modules worden aangezet die normaliter uitstaan op productie.

Ps: om gebruik te maken van het ‘enable’ commando, dien je de file sync_enable.drush.inc te kopieren vanuit je Drush installatiefolder naar je ~/.drush folder.