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
DDD集約とサービスコンテキスト境界との関係性
pandayumi
3
290
「その開発、認知負荷高すぎませんか?」Platform Engineeringで始める開発者体験カイゼン術
sansantech
PRO
2
110
「どこから読む?」コードとカルチャーに最速で馴染むための実践ガイド
zozotech
PRO
0
540
これでもう迷わない!Jetpack Composeの書き方実践ガイド
zozotech
PRO
0
1k
初めてAWSを使うときのセキュリティ覚書〜初心者支部編〜
cmusudakeisuke
1
270
Snowflake Intelligenceにはこうやって立ち向かう!クラシルが考えるAI Readyなデータ基盤と活用のためのDataOps
gappy50
0
270
現場で効くClaude Code ─ 最新動向と企業導入
takaakikakei
1
260
Codeful Serverless / 一人運用でもやり抜く力
_kensh
7
450
5分でカオスエンジニアリングを分かった気になろう
pandayumi
0
250
AWSで始める実践Dagster入門
kitagawaz
1
680
研究開発と製品開発、両利きのロボティクス
youtalk
1
530
CDK CLIで使ってたあの機能、CDK Toolkit Libraryではどうやるの?
smt7174
4
190
Featured
See All Featured
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Become a Pro
speakerdeck
PRO
29
5.5k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Producing Creativity
orderedlist
PRO
347
40k
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.8k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
Speed Design
sergeychernyshev
32
1.1k
Imperfection Machines: The Place of Print at Facebook
scottboms
268
13k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
GitHub's CSS Performance
jonrohan
1032
460k
For a Future-Friendly Web
brad_frost
180
9.9k
How to Think Like a Performance Engineer
csswizardry
26
1.9k
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