Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Node.jsバージョンアップで 困らないためのコミットの読み方 / How to read ...
Search
浅野仁志
September 06, 2023
Technology
0
100
Node.jsバージョンアップで 困らないためのコミットの読み方 / How to read commits so that you don't have to worry about upgrading Node.js / RAKUSMeetup 2023 09
浅野仁志
September 06, 2023
Tweet
Share
More Decks by 浅野仁志
See All by 浅野仁志
特徴、魅力を知って、各PHPフレームワークを使いこなそう! / PHPerkaigi 2023
hitoshi_a0
0
1.5k
Other Decks in Technology
See All in Technology
7月のガバクラ利用料が高かったので調べてみた
techniczna
3
830
開発者を支える Internal Developer Portal のイマとコレカラ / To-day and To-morrow of Internal Developer Portals: Supporting Developers
aoto
PRO
1
110
実践AIガバナンス
asei
3
340
実運用で考える PGO
kworkdev
PRO
0
140
スプリントレトロスペクティブはチーム観察の宝庫? 〜チームの衝突レベルに合わせたアプローチ仮説!〜
electricsatie
1
150
AWSで推進するデータマネジメント
kawanago
0
930
2025年になってもまだMySQLが好き
yoku0825
8
3.8k
新規案件の立ち上げ専門チームから見たAI駆動開発の始め方
shuyakinjo
0
660
PRDの正しい使い方 ~AI時代にも効く思考・対話・成長ツールとして~
techtekt
PRO
1
1.8k
Kiroと学ぶコンテキストエンジニアリング
oikon48
6
8.3k
Agile PBL at New Grads Trainings
kawaguti
PRO
1
210
衝突して強くなる! BLUE GIANTと アジャイルチームの共通点とは ― いきいきと活気に満ちたグルーヴあるチームを作るコツ ― / BLUE GIANT and Agile Teams
naitosatoshi
0
300
Featured
See All Featured
Side Projects
sachag
455
43k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.1k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
We Have a Design System, Now What?
morganepeng
53
7.8k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Building a Modern Day E-commerce SEO Strategy
aleyda
43
7.5k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.4k
How GitHub (no longer) Works
holman
315
140k
Building Better People: How to give real-time feedback that sticks.
wjessup
368
19k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
36
2.5k
Transcript
© RAKUS Co., Ltd. Node.jsバージョンアップで 困らないためのコミットの読み⽅ #RAKUSMeetup 株式会社ラクス 第三開発部 チャットディーラー開発課 浅野
仁志 2023/09/06
⾃⼰紹介 • 名前 浅野 仁志 • 所属 チャットディーラー開発課 • 今までの経験 ◦ PHP 3年
◦ React, Vue 1年 ◦ Node.js 6ヵ⽉ • マイブーム ◦ Docker, k8sとかに興味があります。 2
⽬次 1. チャットディーラーとは 2. Node.jsのバージョンアップの進め⽅ 3. 発⽣した問題点 4. 私達がとった施策について 5.
具体的な影響調査のやり⽅ 6. その効果、結果 7. まとめ 3
チャットディーラーとは • 社内向けAIチャットボット • チャットで質問をするとボットが⾃動で回答する • 管理画⾯からボットの設定を⾏う 4
チャットディーラーで使⽤している技術について • 管理画⾯周り ◦ PHP,Laravel • チャット画⾯周り ◦ Node.js •
機械学習周り ◦ Python 5
チャットディーラーの使⽤している技術について • 管理画⾯周り ◦ PHP,Laravel • チャット画⾯周り ◦ Node.js v14がEOLを迎える •
機械学習周り ◦ Python 6
バージョンアップを担当することに • 私がバージョンアップの担当者に 7 バージョンアップの進め⽅ • バージョンアップ先のバージョンを決定 • 変更履歴などを⾒て、変更内容の把握 •
プロダクトコードの改修 • リリース
バージョンアップの進め⽅ 1. バージョンアップ先のバージョンを決定 調査時点ではv18が最新のLTSバージョンだったので、v18に決定 2. 変更履歴から変更内容の把握 コード差分、Issueの議論などを読む 3. 改修 プロダクトコードに影響がある場合は修正
4. リリース準備&リリース 進めていくと様々な問題点が発覚した 8
バージョンアップに⼯数がかかりすぎる 要因 1. 変更点の量が膨⼤である 2. 1つ1つの変更内容を把握するのに時間がかかる 問題点 9
1. 変更点の量が膨⼤である • v14 → v18 メジャーバージョンアップ4つ分 • コミットレベルでみて516点の変更点があった • 影響の有無に関わらず、全て確認する必要があった
10
2. 変更内容を把握するのに時間がかかる • コミットレベルでコードの差分⾒てもどこに影響するかわからない ◦ 変更内容にNode.jsの内部処理の修正などもある ◦ 内部処理の修正だから影響ないと思いたいが、確信が持てない • チーム内に前任者がおらず、ノウハウがない
• 影響調査の勘所がわからず、無闇に調査する時間が溶けていく 11
私達が取った⼯数削減の施策 1. コードの差分の読み⽅を⼯夫 2. テストで品質を担保 12
コードの差分の読み⽅を⼯夫 13 調査内容 • 変更履歴をコミットレベルで追う • コミット、Issueの議論などを読む コミットの読み⽅で⼯夫したポイント • ドキュメントの修正がないかどうか
• Node.jsのテストコード、ドキュメントで関数の使い⽅(引数等) • Node.jsのテストコードでアサートの期待値の変更が無いか
差分のドキュメント部分だけで下記の変更内容であることがわかる • ヘッダーにhostが新しく設定できるようになった • request.authorityで:authority、hostがどちらかが取得できる ⇒ 新規追加で既存のコードには影響なしと判断できる 具体例: ドキュメントから影響を判断 14
具体例: テストコードから影響を判断する場合 • Node.js本体のコードから変更内容を把握するにはかなりの⼯数 がかかる場合がある • テストコードから影響判断することも考える • テストコードが追加されていて、他のテストコードに変更なし 既存の動きには影響がないため、改修が不要だろう
writeの第3引数に例外発⽣時のコールバックが設定可能になった 15
具体例: 上記の⼿順でもわかない場合 • どうしようもないから、テストで担保する • もし関連しそうな機能がわかるなら、テストケースを厚くする 16
2. テストで品質を担保 • コミットの変更内容を読み解きたいが、わからない場合がある • 影響範囲をリストアップしてその範囲を重点的にテストする ◦ 少しでもバグが発⽣する確率を下げる 17
変更対象のメソッドはわかるが、変更内容がわからない 概要:fs: use kResistStopPropagation • fsモジュールに対する変更。どういう影響があるのかわかない • まずプロダクトコードで対象のモジュールが使⽤しているのか調査 • プロダクトコードでfsモジュールを使っていない場合
◦ 影響がないので、改修不要と判断 • プロダクトコードでfsモジュールを使っている場合 ◦ テストケースを厚くもたせる 18
得られた効果、結果 良かった点 • 基準があると⾃信を持って影響調査を進められる • 影響範囲の理解が容易になった • ⼯数の短縮 懸念点 •
Node.jsのテストコードを信じることになるので、注意が必要です 19 前回の実績 今回の実績 6ヵ月 2ヵ月
調査した感想 • v14→v18の場合、Node.jsには致命的な変更はなかった • Node.jsはパッケージのほうが⼤変な場合が多い ◦ Node.jsの影響調査で⼯数を削減 ◦ パッケージの影響調査に⼯数をかけることができる 20
まとめ • 全てを理解というより、今回進めたような調査のやり⽅で進め ることをおすすめ • 品質と⼯数とのバランスを意識し、ある程度割り切ってテスト で品質を担保という⽅法を取る 今回紹介した⽅法が助けになれば幸いです 21
ご清聴ありがとうございました 22