Slide 1

Slide 1 text

Drupal and Continuous Integration DrupalCampNJ - 2014

Slide 2

Slide 2 text

Who we are Henry Umansky Princeton University humansky@princeton. edu Jason Howe Drew University [email protected]

Slide 3

Slide 3 text

What is Continuous Integration? “Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day.” -Martin Fowler

Slide 4

Slide 4 text

Principles of CI? ● Maintain a code repository ● Automate the build ● Make the build self-testing ● Everyone commits to the baseline every day ● Every commit (to baseline) should be built ● Keep the build fast

Slide 5

Slide 5 text

Principles of CI (cont’d) ● Test in a clone of the production environment ● Make it easy to get the latest deliverables ● Everyone can see the results of the latest build ● Automate deployment

Slide 6

Slide 6 text

Advantages of CI ● prevent integration problems ● identify failing code early ● immediate unit testing of all changes ● "current" build for testing, demo, or releases

Slide 7

Slide 7 text

Disadvantages of CI ● Initial setup time required ● Well-developed test-suite required to achieve automated testing advantages

Slide 8

Slide 8 text

Maintain a code repository ● Version Control Systems: git or svn ● use Features as much as possible ● Strongarm Module

Slide 9

Slide 9 text

Automate the Build ● Hudson/Jenkins ● Drush ● Build triggers

Slide 10

Slide 10 text

Make the build self-testing ● Drupal Coder Review/Security Review ● Code Quality - [ php | css | js ] lint ● PhantomJS and Selenium ● Checkstyles/PHPMD

Slide 11

Slide 11 text

Daily Commits ● Commit at least once a day ● Reduces potential conflicts ● Triggers automated builds

Slide 12

Slide 12 text


Slide 13

Slide 13 text

Automated Deployment ● Identical /dev/qa/prod systems ● Trivial to move code between environments ● Single button click to perform complex tasks

Slide 14

Slide 14 text

Automated Deployment ● Single button click to deploy production code to n webservers. ● Deployment is simply a “git pull”, executed via remote ssh. ● Auto deployment to dev upon code commit to dev.

Slide 15

Slide 15 text

Achieving Identical Environments ● Everything has to be automated, no lovingly handcrafted environments. ● Bash script fired by Jenkins, builds databases, instantiates drupal instance in all environments. ● Tools to sync content from prod->dev and code from dev->prod

Slide 16

Slide 16 text

Known state of environments ● You always know that Dev contains everyone’s latest contributions. ● You always know that Prod is a copy of what’s in the repo.

Slide 17

Slide 17 text

From the Operations Perspective ● Keep Server configs in (my.cnf, http.conf, etc) in a configuration repository. ● New webhead is trivial: ○ checkout config repo and run setup script. ○ symlinks config files, checkout drupal. ○ Essentially a self-configuring server ● Works for DR too!

Slide 18

Slide 18 text

Other Advantages for Ops ● Knowing, without a doubt the current system state. ● Ability to spin up a test environment in minutes. ● Aids in troubleshooting and quick issue resolution. (Good comments commits help too)

Slide 19

Slide 19 text