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.staEcflickr.com/8471/8135313427_44c72f8d52_c.jpg  

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)  

 

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  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  

git fetch upstream git merge upstream/master (resolve  conflicts  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