“Code, Test, Review, Review, Test, Repeat, Release” This is how we develop as a Team

"CODE, TEST, REVIEW, REVIEW, TEST, RELEASE, ... AND REPEAT" THIS IS HOW WE DEVELOP AS A

TEAMDoug Green

@dougjgreen#fldc14 #druplart

What’s up with the title?● You write Code● You Test your own code● You Review your own code● Someone else Review’s your code● Someone else Test’s your code● … repeat● Somewhere above a bot Test’s the code● And finally someone else Test’s your code

Overview

1. Teams2. Using Git and github3. Write good code4. Code reviews5. An agile process6. Automated Testing using Behat7. Q & A

1. Teams

● You are already part of the “Drupal” Team● Use a chat room like IRC even if you work in

the same location● Have meetings in IRC● Discuss problems in IRC● Try to solve things yourself first, but ask for

help if you are stuck

2. Overview of git and githubA. What is git? What is github? Why use them?B. Create a project repo in github, add Drupal and contrib

modules as they are downloaded from d.o, grant team members access to the project account

C. Fork the repo to your individual accountD. Create a local repository with remotes; also create

upstream develop branchE. Do work … Make a pull requestF. More about git: rebase, cherry-pick

https://github.com/douggreenconsulting/fldc14

B

CREATE

REPO

C

FORK

ORG

REPO

D. Setup your local repository● $ git clone git@github.com:douggreen/fldc14.git

○ This will add the remote “origin”● $ git remote add upstream git@github.com:

douggreenconsulting/fldc14.git● $ git checkout -b develop● $ git push upstream develop● $ git push origin develop● $ git checkout -b feature-1234

○ Do work● $ git checkin -m’Initial commit of fldc14 module’

E

PULL REQUEST

3. Write good code● follow coding standards, why ...● use Drupal API’s● refactor to minimize duplicative code● use standard names for things● use tools like coder and php code sniffer● configure your editor to automatically indent and replace

tabs, phpstorm is excellent

More about git

● $ git rebase develop● $ git cherry-pick 74c0d02● ~/.gitconfig:

[alias] ci = commit -a switch = checkout praise = blame

Write good code by testing it!In order of priority, from the very least to the gold standard1. locally always use $error_level = 2

○ settings.php or drush sync_enable2. check for syntax errors

○ php -l3. visit the home page, look for warnings4. write test instructions for others, note possible edge cases5. follow your own test instructions manually6. check watchdog log

○ drush wd-show --tail7. write test instructions in Gherkin8. run Gherkin tests in Behat

4. Code Reviews● patterns, standards● check for proper API usage● check for consistent internal function calls● check for standardized naming of things● check for good comments, sentences, and that the

comment make sense. We want maintainable code.● pull locally if you must, sometimes diffs are hard to read● can this custom change be a patch, contrib module, did

you include a patch file in the patches/ directory?

You can use git instead of github

$ git remote add doug origin git@github.com:douggreen/fldc14.git$ git pull doug ticket-1234$ git checkout develop$ git pull doug ticket-1234

● you’ll be asked for a merge comment here$ git push upstream develop

Coding for dev/qa/prod releases● Use update handlers, never ask a RM to click on

something, it’s not reproducible: module_enable, configuration changes, field creation, everything

● local.settings.inc, included from settings.php, symlinked per environment, include dbsettings.inc from local.settings.inc

● $conf[‘var’] in settings.php instead of variable_set● put Drupal and contrib and patches in repository so that

you can deploy everything together, and you can maintain upgrades knowing the patch’s to re-apply

An agile process

● Somewhat discussed in Drupal Watchdog “Release Management ‘On The Truck’” http://drupalwatchdog.com/1/1/release-management-on-the-truck

● Weekly sprints (5 Business Days)● Day 1: take risk● Day 3-4: solidify release, no regressions● Day 5: release● It takes practice to work on a weekly sprint

Behat Automated Testing● Takes real commitment from an organization to write

automated tests● every developer should write tests● or team of test writers, to do it right, need a team almost

as big as the dev team● or pair a test writer with a developer on each task● devs should run tests locally before big PR’s● best if test results are added to github PR’s● Use drupalextension, but extend it with your own

context

Q&A

Doug Green@dougjgreen

#fldc14 #druplart