Post on 17-Jul-2015
Drupal, git and sanity
Charlie Morris Penn State University Libraries
@cdmo
Code4lib 2015 | Portland, Oregon
our scenario
• migraEng into Drupal from proprietary system • one big academic library site • many smaller library sites and sites under the auspices of the libraries
• mulEple developers leading and collaboraEng on projects
• lots of new
some potenEal opEons for managing drupal projects
• put all the things in the drupal file tree in a repo
• whole file tree + git submodules for core + contrib code
• create many repos for the many custom modules and themes in your drupal file tree – (and figure out how to handle seWngs.php, .htaccess and /sites/all/libraries modificaEons)
how we are doing it
• just managing all of our own code in one repo (modules, theme, .htaccess mods, libraries…)
• aggressive giEgnore for stuff drush can take care of
• use features and strongarm modules for storing as much db config in code as possible
• drush sql-‐sync to keep dev environments in sync with live dbs
a “base build” or “the upstream”
• created a base build that contains the common theme, module, and other custom code that drush wouldn’t be used to manage
the basic idea
1. clone the base build and install via bash script
2. new project gets 2 remotes: origin and upstream
3. projects are developed on origin 4. periodic fetching and merging of upstream
(devs noEfied when changes occur via Slack) 5. drush adds/manages/updates core, contrib
end result (hopefully)
• staying in sync • least pain possible for updaEng/maintaining • less Eme on DevOps • more Eme learning all the other new things • more Eme building beJer user experiences