Tweet
Tweet

Slide 1

Slide 1 text

Continuous Gem Dependency Updating with Jenkins and Pull Request #rubykaigi2013 @kyanny

Slide 2

Slide 2 text

Welcome! Thanks for coming :) After greeting, Japanese speech & English translation

Slide 3

Slide 3 text

Kensuke nagae @kyanny

Slide 4

Slide 4 text

• ௕Ӭ ݈հ (ͳ͕͑ ͚Μ͚͢) • ࢗ਎ˑϒʔϝϥϯ (sashimi boomerang) • @kyanny • Web Application Developer, Rubyist • Joined to Quipper this week

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

Continuous Gem Dependency Updating with Jenkins and Pull Request #rubykaigi2013 @kyanny

Slide 8

Slide 8 text

What I want to tell you today Continuous improvement is important. You may be able to do.

Slide 9

Slide 9 text

Agenda • Gem basis: rubygems and Bundler • Issues related to continuous gem dependency updating • How I solved it • Compare my solution with other ways

Slide 10

Slide 10 text

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.

Slide 11

Slide 11 text

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!

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

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.

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

How to update: run bundle update. Simple. Looks very easy, but... “Continuously” is not such a easy.

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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.

Slide 21

Slide 21 text

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.

Slide 22

Slide 22 text

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.

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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.

Slide 25

Slide 25 text

Automation Run bundle update by

Slide 26

Slide 26 text

$ bundle update $ git add Gemfile.lock $ git commit -m “bundle update” $ bundle exec rake spec

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

Visualization +

Slide 29

Slide 29 text

$ git checkout -b \ bundle-update-YYYYMMDD $ bundle update $ git add Gemfile.lock $ git commit -m “bundle update” $ bundle exec rake spec $ hub pull-request

Slide 30

Slide 30 text

Benefit • It’s conspicuous • Developer wants to review and to merge pull request • Easy to check diff • Sense of duty

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

No content

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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.

Slide 39

Slide 39 text

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.

Slide 40

Slide 40 text

Happy side effect: Contribution :)

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

No content

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

Conclusion • Importance of continuously gem updating • Three reasons why it’s hard • Automate bundle update by Jenkins • Visualize it by Pull Request

Slide 46

Slide 46 text

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!

Slide 47

Slide 47 text

Thank you!