Pro Yearly is on sale from $80 to $50! »

Continuous gem dependency updating with Jenkins and Pull Request

Continuous gem dependency updating with Jenkins and Pull Request

RubyKaigi 2013, May 30 - Jun 1
Presented by Kensuke Nagae (@kyanny)
http://rubykaigi.org/2013/talk/S72

Fffd8bf62b842a46803fb07792029fa4?s=128

Kensuke Nagae

May 31, 2013
Tweet

Transcript

  1. Continuous Gem Dependency Updating with Jenkins and Pull Request #rubykaigi2013

    @kyanny
  2. Welcome! Thanks for coming :) After greeting, Japanese speech &

    English translation
  3. Kensuke nagae @kyanny

  4. • ௕Ӭ ݈հ (ͳ͕͑ ͚Μ͚͢) • ࢗ਎ˑϒʔϝϥϯ (sashimi boomerang) •

    @kyanny • Web Application Developer, Rubyist • Joined to Quipper this week
  5. None
  6. None
  7. Continuous Gem Dependency Updating with Jenkins and Pull Request #rubykaigi2013

    @kyanny
  8. What I want to tell you today Continuous improvement is

    important. You may be able to do.
  9. Agenda • Gem basis: rubygems and Bundler • Issues related

    to continuous gem dependency updating • How I solved it • Compare my solution with other ways
  10. Gem is package format for Ruby’s library. RubyGems is package

    manager. Gem has gemspec for metadata, including dependency information. When we install gem, RubyGems solves gem’s dependencies, so required gem(s) will be installed automatically.
  11. RubyGems is wise and powerful, but it’s not enough from

    application’s viewpoint. Application uses many gems. Where is the place to write these dependencies? We want to manage it with application itself. Bundler!
  12. None
  13. Gems will be updated every day. Your application might depends

    on many gems, therefore your application should be updated every day. Developer must update gems continuously.
  14. MUST? Really? “My application works well without updating” “My boss

    might not allow to spend time for updating” etc.
  15. MUST? Really? “My application works well without updating” “My boss

    might not allow to spend time for updating” etc. YES! WE SHOULD!
  16. None
  17. None
  18. How to update: run bundle update. Simple. Looks very easy,

    but... “Continuously” is not such a easy.
  19. Three reasons why it’s hard 1. Motivation-driven operation is not

    sustainable 2. The work does not incorporate with daily workflow would be forgotten 3. Email notification lacks sense of duty
  20. 1st reason Everyone once decided to check update everyday. If

    you have enough motivation, it works. Unfortunately, your motivation will be lost eventually. Motivation-driven operation is not sustainable.
  21. 2nd reason I mentioned bundle update. Simple. However, developers are

    so busy that unusual work would be forgotten. You might check mailbox without thinking, but you might not run bundle update just like it.
  22. 3rd reason I know bundle outdated, of course. $ bundle

    outdated | mail Easy to automate notification. But it has less pressure, so it’s easy to ignore.
  23. Three reasons why it’s hard (again) 1. Motivation-driven operation is

    not sustainable 2. The work does not incorporate with daily workflow would be forgotten 3. Email notification lacks sense of duty
  24. How to solve it? • Automation. Build system that work

    without motivation. • Visualization. Publicize whole process of system. Take it into your daily work. It makes a sense of mission.
  25. Automation Run bundle update by

  26. $ bundle update $ git add Gemfile.lock $ git commit

    -m “bundle update” $ bundle exec rake spec
  27. (Work in Progress) Automation is good, but developer still have

    to make decision apply the update or not. How to tell him? Email? NO! Send Pull Request!
  28. Visualization +

  29. $ git checkout -b \ bundle-update-YYYYMMDD $ bundle update $

    git add Gemfile.lock $ git commit -m “bundle update” $ bundle exec rake spec $ hub pull-request
  30. Benefit • It’s conspicuous • Developer wants to review and

    to merge pull request • Easy to check diff • Sense of duty
  31. None
  32. None
  33. None
  34. None
  35. None
  36. Daily workflow (1) • Jenkins runs job every morning •

    If opened Pull Request... • Check whether tests passed or failed • If tests failed... • Fix tests as soon as possible
  37. Daily workflow (2) • Check diff of Pull Request updated_gems.each

    { Changelog.read git diff v1.2.3..v4.5.6 git log } • Merge branch as soon as possible
  38. I like to fix broken tests, even though it gives

    a load. It’s the sign that application could not follow library update. version fixed! / stop improvement It’s trade-off.
  39. bundler-auto-update is similar way. It updates all gems to the

    most recent version that does not break tests. My solution has more aggressive strategy. Tests are safety net. Earlier break, earlier fix.
  40. Happy side effect: Contribution :)

  41. None
  42. None
  43. None
  44. “Open source contirbution” sounds tough. “Social coding” seems more easy,

    but... Daily Pull Request gave me the chance. And also, I could know more about various gems.
  45. Conclusion • Importance of continuously gem updating • Three reasons

    why it’s hard • Automate bundle update by Jenkins • Visualize it by Pull Request
  46. My case is a trivial thing. But there are so

    many trivial things to be solved. Continuous improvement makes our environment more better. “Kaizen” was not built in a day. Next is your turn!
  47. Thank you!