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

core + contrib + custom

hJp://farm9.staEcickr.com/8471/8135313427_44c72f8d52_c.jpg

some potenEal opEons for managing drupal projects

put all the things in the drupal le tree in a repo

whole le tree + git submodules for core + contrib code

create many repos for the many custom modules and themes in your drupal le tree (and gure out how to handle seWngs.php, .htaccess and /sites/all/libraries modicaEons)

sEll the problem of updaEng the database aYer updaEng core and

contrib

how we are doing it

just managing all of our own code in one repo (modules, theme, .htaccess mods, libraries)

aggressive giEgnore for stu drush can take care of

use features and strongarm modules for storing as much db cong 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 wouldnt 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 noEed when changes occur via Slack) 5. drush adds/manages/updates core, contrib

git fetch upstream git merge upstream/master (resolve conicts as needed)

link

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

thanks! base build upstream repo at hJps://github.com/cdmo/psu-libraries-drupal quesEons/feedback? Charlie Morris Penn State Libraries @cdmo