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

707 views
595 views

Published on

Presentation from Florida Drupal Camp 2014

https://fldrupalcamp.org/florida-drupalcamp-2014/session/code-test-review-review-test-release-and-repeat-how-we-develop-team

I have a few things to say about Teams. Working in a Team is very important to me. We’re going to spend a lot of time talking about git and github and writing good code and a little time reviewing code. There’s not going to be enough time to show many of the details types of things I typically look for in Code Reviews.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
707
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
4
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

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

  1. 1. “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 HOWDoug Green WE DEVELOP AS A @dougjgreen TEAM #fldc14 #druplart
  2. 2. 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
  3. 3. Overview 1. 2. 3. 4. 5. 6. 7. Teams Using Git and github Write good code Code reviews An agile process Automated Testing using Behat Q&A
  4. 4. 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
  5. 5. 2. Overview of git and github A. 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 account D. Create a local repository with remotes; also create upstream develop branch E. Do work … Make a pull request F. More about git: rebase, cherry-pick https://github.com/douggreenconsulting/fldc14
  6. 6. B C R E A T E R E P O
  7. 7. C F O R K O R G R E P O
  8. 8. 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’
  9. 9. E P U L L R E Q U E S T
  10. 10. 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
  11. 11. More about git ● $ git rebase develop ● $ git cherry-pick 74c0d02 ● ~/.gitconfig: [alias] ci = commit -a switch = checkout praise = blame
  12. 12. Write good code by testing it! In order of priority, from the very least to the gold standard 1. 2. 3. 4. 5. 6. 7. 8. locally always use $error_level = 2 ○ settings.php or drush sync_enable check for syntax errors ○ php -l visit the home page, look for warnings write test instructions for others, note possible edge cases follow your own test instructions manually check watchdog log ○ drush wd-show --tail write test instructions in Gherkin run Gherkin tests in Behat
  13. 13. 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?
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. Q&A Doug Green @dougjgreen #fldc14 #druplart

×