Node.jsバージョンアップで 困らないためのコミットの読み方 / How to read commits so that you don't have to worry about upgrading Node.js / RAKUSMeetup 2023 09

Transcript

1. © RAKUS Co., Ltd.
   Node.jsバージョンアップで
   困らないためのコミットの読み⽅
   #RAKUSMeetup
   株式会社ラクス 
   第三開発部 チャットディーラー開発課
   浅野 仁志
   2023/09/06
   

   View Slide

2. ⾃⼰紹介
   ● 名前 浅野 仁志
   ● 所属 チャットディーラー開発課
   ● 今までの経験
   ○ PHP 3年
   ○ React, Vue 1年
   ○ Node.js 6ヵ⽉
   ● マイブーム
   ○ Docker, k8sとかに興味があります。
   2
   

   View Slide

3. ⽬次
   1. チャットディーラーとは
   2. Node.jsのバージョンアップの進め⽅
   3. 発⽣した問題点
   4. 私達がとった施策について
   5. 具体的な影響調査のやり⽅
   6. その効果、結果
   7. まとめ
   3
   

   View Slide

4. チャットディーラーとは
   ● 社内向けAIチャットボット
   ● チャットで質問をするとボットが⾃動で回答する
   ● 管理画⾯からボットの設定を⾏う
   4
   

   View Slide

5. チャットディーラーで使⽤している技術について
   ● 管理画⾯周り
   ○ PHP,Laravel
   ● チャット画⾯周り
   ○ Node.js
   ● 機械学習周り
   ○ Python
   5
   

   View Slide

6. チャットディーラーの使⽤している技術について
   ● 管理画⾯周り
   ○ PHP,Laravel
   ● チャット画⾯周り
   ○ Node.js v14がEOLを迎える
   ● 機械学習周り
   ○ Python
   6
   

   View Slide

7. バージョンアップを担当することに
   ● 私がバージョンアップの担当者に
   7
   バージョンアップの進め⽅
   ● バージョンアップ先のバージョンを決定
   ● 変更履歴などを⾒て、変更内容の把握
   ● プロダクトコードの改修
   ● リリース
   

   View Slide

8. バージョンアップの進め⽅
   1. バージョンアップ先のバージョンを決定
   調査時点ではv18が最新のLTSバージョンだったので、v18に決定
   2. 変更履歴から変更内容の把握
   コード差分、Issueの議論などを読む
   3. 改修
   プロダクトコードに影響がある場合は修正
   4. リリース準備＆リリース
   進めていくと様々な問題点が発覚した
   8
   

   View Slide

9. バージョンアップに⼯数がかかりすぎる
   要因
   1. 変更点の量が膨⼤である
   2. １つ１つの変更内容を把握するのに時間がかかる
   問題点
   9
   

   View Slide

10. 1. 変更点の量が膨⼤である
    ● v14 → v18 メジャーバージョンアップ4つ分
    ● コミットレベルでみて516点の変更点があった
    ● 影響の有無に関わらず、全て確認する必要があった
    10
    

    View Slide

11. 2. 変更内容を把握するのに時間がかかる
    ● コミットレベルでコードの差分⾒てもどこに影響するかわからない
    ○ 変更内容にNode.jsの内部処理の修正などもある
    ○ 内部処理の修正だから影響ないと思いたいが、確信が持てない
    ● チーム内に前任者がおらず、ノウハウがない
    ● 影響調査の勘所がわからず、無闇に調査する時間が溶けていく
    11
    

    View Slide

12. 私達が取った⼯数削減の施策
    1. コードの差分の読み⽅を⼯夫
    2. テストで品質を担保
    12
    

    View Slide

13. コードの差分の読み⽅を⼯夫
    13
    調査内容
    ● 変更履歴をコミットレベルで追う
    ● コミット、Issueの議論などを読む
    コミットの読み⽅で⼯夫したポイント
    ● ドキュメントの修正がないかどうか
    ● Node.jsのテストコード、ドキュメントで関数の使い⽅（引数等）
    ● Node.jsのテストコードでアサートの期待値の変更が無いか
    

    View Slide

14. 差分のドキュメント部分だけで下記の変更内容であることがわかる
    ● ヘッダーにhostが新しく設定できるようになった
    ● request.authorityで:authority、hostがどちらかが取得できる
    ⇒ 新規追加で既存のコードには影響なしと判断できる
    具体例: ドキュメントから影響を判断
    14
    

    View Slide

15. 具体例: テストコードから影響を判断する場合
    ● Node.js本体のコードから変更内容を把握するにはかなりの⼯数
    がかかる場合がある
    ● テストコードから影響判断することも考える
    ● テストコードが追加されていて、他のテストコードに変更なし
    既存の動きには影響がないため、改修が不要だろう
    writeの第3引数に例外発⽣時のコールバックが設定可能になった 15
    

    View Slide

16. 具体例: 上記の⼿順でもわかない場合
    ● どうしようもないから、テストで担保する
    ● もし関連しそうな機能がわかるなら、テストケースを厚くする
    16
    

    View Slide

17. 2. テストで品質を担保
    ● コミットの変更内容を読み解きたいが、わからない場合がある
    ● 影響範囲をリストアップしてその範囲を重点的にテストする
    ○ 少しでもバグが発⽣する確率を下げる
    17
    

    View Slide

18. 変更対象のメソッドはわかるが、変更内容がわからない
    概要：fs: use kResistStopPropagation
    ● fsモジュールに対する変更。どういう影響があるのかわかない
    ● まずプロダクトコードで対象のモジュールが使⽤しているのか調査
    ● プロダクトコードでfsモジュールを使っていない場合
    ○ 影響がないので、改修不要と判断
    ● プロダクトコードでfsモジュールを使っている場合
    ○ テストケースを厚くもたせる
    18
    

    View Slide

19. 得られた効果、結果
    良かった点
    ● 基準があると⾃信を持って影響調査を進められる
    ● 影響範囲の理解が容易になった
    ● ⼯数の短縮
    懸念点
    ● Node.jsのテストコードを信じることになるので、注意が必要です
    19
    前回の実績 今回の実績
    ６ヵ月 ２ヵ月
    

    View Slide

20. 調査した感想
    ● v14→v18の場合、Node.jsには致命的な変更はなかった
    ● Node.jsはパッケージのほうが⼤変な場合が多い
    ○ Node.jsの影響調査で⼯数を削減
    ○ パッケージの影響調査に⼯数をかけることができる
    20
    

    View Slide

21. まとめ
    ● 全てを理解というより、今回進めたような調査のやり⽅で進め
    ることをおすすめ
    ● 品質と⼯数とのバランスを意識し、ある程度割り切ってテスト
    で品質を担保という⽅法を取る
    今回紹介した⽅法が助けになれば幸いです
    21
    

    View Slide

22. ご清聴ありがとうございました
    22
    

    View Slide